Re: [PATCH v2 22/25] powerpc32: move xxxxx_dcache_range() functions inline

On Tue, 2015-09-22 at 15:35 -0500, Scott Wood wrote:

On Tue, 2015-09-22 at 20:32 +0000, Joakim Tjernlund wrote:

quoted

On Tue, 2015-09-22 at 15:14 -0500, Scott Wood wrote:

quoted

On Tue, 2015-09-22 at 19:55 +0000, Joakim Tjernlund wrote:

quoted

On Tue, 2015-09-22 at 14:42 -0500, Scott Wood wrote:

quoted

On Tue, 2015-09-22 at 19:34 +0000, Joakim Tjernlund wrote:

quoted

On Tue, 2015-09-22 at 13:58 -0500, Scott Wood wrote:

quoted

On Tue, 2015-09-22 at 18:12 +0000, Joakim Tjernlund wrote:

quoted

On Tue, 2015-09-22 at 18:51 +0200, Christophe Leroy wrote:

quoted

flush/clean/invalidate _dcache_range() functions are all =

very

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

similar and are quite short. They are mainly used in=20
__dma_sync()
perf_event locate them in the top 3 consumming functions=

=20

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

during
heavy ethernet activity
=20
They are good candidate for inlining, as __dma_sync() doe=

s

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

almost nothing but calling them
=20
Signed-off-by: Christophe Leroy <redacted>
---
New in v2
=20
 arch/powerpc/include/asm/cacheflush.h | 55=20
+++++++++++++++++++++++++++--
 arch/powerpc/kernel/misc_32.S         | 65 -------------=

-----

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

----
----
----
-----
 arch/powerpc/kernel/ppc_ksyms.c       |  2 ++
 3 files changed, 54 insertions(+), 68 deletions(-)
=20

diff --git a/arch/powerpc/include/asm/cacheflush.h=20

b/arch/powerpc/include/asm/cacheflush.h
index 6229e6b..6169604 100644

--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h

@@ -47,12 +47,61 @@ static inline void=20

__flush_dcache_icache_phys(unsigned long physaddr)
 }
 #endif
=20
-extern void flush_dcache_range(unsigned long start, unsi=

gned=20

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

long=20
stop);
 #ifdef CONFIG_PPC32
-extern void clean_dcache_range(unsigned long start, unsi=

gned=20

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

long=20
stop);
-extern void invalidate_dcache_range(unsigned long start,=

=20

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

unsigned=20
long=20
stop);
+/*
+ * Write any modified data cache blocks out to memory an=

d=20

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

invalidate=20
them.
+ * Does not invalidate the corresponding instruction cac=

he=20

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

blocks.
+ */
+static inline void flush_dcache_range(unsigned long star=

t,=20

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

unsigned=20
long=20
stop)
+{
+   void *addr =3D (void *)(start & ~(L1_CACHE_BYTES - 1)=

);

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

+   unsigned int size =3D stop - (unsigned long)addr +=20
(L1_CACHE_BYTES -
1);
+   unsigned int i;
+
+   for (i =3D 0; i < size >> L1_CACHE_SHIFT; i++, addr +=

=3D=20

quoted

quoted

quoted

quoted

quoted

quoted

quoted

quoted

L1_CACHE_BYTES)
+           dcbf(addr);
+   if (i)
+           mb();   /* sync */
+}

=20
This feels optimized for the uncommon case when there is no=

=20

quoted

quoted

quoted

quoted

quoted

quoted

quoted

invalidation.

=20
If you mean the "if (i)", yes, that looks odd.

=20
Yes.
=20

quoted

=20

quoted

I THINK it would be better to bail early=20

=20
Bail under what conditions?

=20
test for "i =3D 0" and return.=20

=20
Why bother?

=20
I usally find it better to dela with special cases upfront s=E5 the=

 rest=20

quoted

quoted

quoted

doesn't need to
bother. i=3D0 is a NOP and it is clearer to show that upfront.

=20
No, I mean why bother special casing this at all?

=20
I just said why?=20
You to found the if(i) mb() a bit odd and it took a little time to see =

why=20

quoted

it was there.
Ahh, you mean just skip the if(i) and have mb() unconditionally?

=20
Yes.
=20

quoted

That changes the semantics a little from the ASM version but perhaps th=

at=20

quoted

doesn't matter?

=20
Adding more barriers than strictly necessary is a performance concern, no=

t a=20

semantic change.

Semantics :)

  How often are we really calling this function over an empty=20
range?

Never hopefully, it does not make much sense.

=20
Not that it matters much one way or another...

probably not.