[CFT:PATCH] Remove a seemingly unnecessary cache flush

[CFT:PATCH] Remove a seemingly unnecessary cache flush

[Russell King - ARM Linux]

While looking into the possible msync() issue (which turned out to be a
non-issue - it's covered by clever code), I found that we're flushing
the same page multiple times.

Normally, update_mmu_cache() would not be doing anything on architectures
which don't have a software-loaded TLB.  However, we use this hook for
two things:

1. for our delayed flush_dcache_page().
2. to fix up multiple shared write-able mappings of the same page.

However, as of 8 years ago, I committed this patch (sorry for the
bkbits URL):

http://linux.bkbits.net:8080/linux-2.6/?PAGE=patch&REV=3dd7c1f9DypjNd1HyQFAOsA3p7mYig

What the majority of that patch is doing is adding the user-mapping
flushing to __flush_dcache_page() - that's fine, and it's explained in
the changeset comments.

It also tries to merge the new __flush_dcache_page() code inside
make_coherent() - make_coherent() is sort-of already doing most of what
__flush_dcache_page() does, and for good measure it does a final
flush_cache_page().

The unused addition of 'dirty' seems to suggest that this extra
flush_cache_page should have been conditional on that.

Moreover, this final flush_cache_page() should not be needed - the whole
"delayed flush_dcache_page" thing only happens when there are no pre-
existing mappings of the page, and so there should be no user mappings
to worry about.

Hence, I believe it is safe to get rid of this - but this patch will
need some rigorous testing.  My ARM VersatilePB926 still boots without
this additional patch - but that's not a very good test.  I can't say
much more than that for the time being.

Note: for ARMv6 and later, flush_cache_page() is a no-op, so please
don't bother testing this patch there.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 arch/arm/mm/fault-armv.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/fault-armv.c b/arch/arm/mm/fault-armv.c
index 7296022..666a871 100644
--- a/arch/arm/mm/fault-armv.c
+++ b/arch/arm/mm/fault-armv.c
@@ -127,8 +127,6 @@ make_coherent(struct address_space *mapping, struct vm_area_struct *vma, unsigne
 	flush_dcache_mmap_unlock(mapping);
 	if (aliases)
 		adjust_pte(vma, addr);
-	else
-		flush_cache_page(vma, addr, pfn);
 }
 
 /*

[CFT:PATCH] Remove a seemingly unnecessary cache flush

[Russell King - ARM Linux]

On Mon, Dec 07, 2009 at 10:12:10PM +0000, Russell King - ARM Linux wrote:
> While looking into the possible msync() issue (which turned out to be a
> non-issue - it's covered by clever code), I found that we're flushing
> the same page multiple times.

I'm going to queue this patch up today since I believe it is correct,
though it would be nice to have a few more people test it on pre-ARMv6
hardware.

[CFT:PATCH] Remove a seemingly unnecessary cache flush

[Mikael Pettersson]

Russell King - ARM Linux writes:
 > On Mon, Dec 07, 2009 at 10:12:10PM +0000, Russell King - ARM Linux wrote:
 > > While looking into the possible msync() issue (which turned out to be a
 > > non-issue - it's covered by clever code), I found that we're flushing
 > > the same page multiple times.
 > 
 > I'm going to queue this patch up today since I believe it is correct,
 > though it would be nice to have a few more people test it on pre-ARMv6
 > hardware.

Tested here with gcc and glibc builds and testsuite runs on IXP420,
IOP80219, and Kirkwood (Feroceon?), all ARMv5TE. No signs of problems.

/Mikael

[CFT:PATCH] Remove a seemingly unnecessary cache flush

[Russell King - ARM Linux]

On Mon, Dec 14, 2009 at 12:50:11PM +0100, Mikael Pettersson wrote:
> Russell King - ARM Linux writes:
>  > On Mon, Dec 07, 2009 at 10:12:10PM +0000, Russell King - ARM Linux wrote:
>  > > While looking into the possible msync() issue (which turned out to be a
>  > > non-issue - it's covered by clever code), I found that we're flushing
>  > > the same page multiple times.
>  > 
>  > I'm going to queue this patch up today since I believe it is correct,
>  > though it would be nice to have a few more people test it on pre-ARMv6
>  > hardware.
> 
> Tested here with gcc and glibc builds and testsuite runs on IXP420,
> IOP80219, and Kirkwood (Feroceon?), all ARMv5TE. No signs of problems.

Do the builds appear to be any faster?

[CFT:PATCH] Remove a seemingly unnecessary cache flush

[Mikael Pettersson]

Russell King - ARM Linux writes:
 > On Mon, Dec 14, 2009 at 12:50:11PM +0100, Mikael Pettersson wrote:
 > > Russell King - ARM Linux writes:
 > >  > On Mon, Dec 07, 2009 at 10:12:10PM +0000, Russell King - ARM Linux wrote:
 > >  > > While looking into the possible msync() issue (which turned out to be a
 > >  > > non-issue - it's covered by clever code), I found that we're flushing
 > >  > > the same page multiple times.
 > >  > 
 > >  > I'm going to queue this patch up today since I believe it is correct,
 > >  > though it would be nice to have a few more people test it on pre-ARMv6
 > >  > hardware.
 > > 
 > > Tested here with gcc and glibc builds and testsuite runs on IXP420,
 > > IOP80219, and Kirkwood (Feroceon?), all ARMv5TE. No signs of problems.
 > 
 > Do the builds appear to be any faster?

I didn't record how long it took because I was mainly interested in
the correctness aspect. I can do a pair of properly measured gcc
builds on the fastest machine next weekend.

[CFT:PATCH] Remove a seemingly unnecessary cache flush

[Mikael Pettersson]

Mikael Pettersson writes:
 > Russell King - ARM Linux writes:
 >  > On Mon, Dec 14, 2009 at 12:50:11PM +0100, Mikael Pettersson wrote:
 >  > > Russell King - ARM Linux writes:
 >  > >  > On Mon, Dec 07, 2009 at 10:12:10PM +0000, Russell King - ARM Linux wrote:
 >  > >  > > While looking into the possible msync() issue (which turned out to be a
 >  > >  > > non-issue - it's covered by clever code), I found that we're flushing
 >  > >  > > the same page multiple times.
 >  > >  > 
 >  > >  > I'm going to queue this patch up today since I believe it is correct,
 >  > >  > though it would be nice to have a few more people test it on pre-ARMv6
 >  > >  > hardware.
 >  > > 
 >  > > Tested here with gcc and glibc builds and testsuite runs on IXP420,
 >  > > IOP80219, and Kirkwood (Feroceon?), all ARMv5TE. No signs of problems.
 >  > 
 >  > Do the builds appear to be any faster?
 > 
 > I didn't record how long it took because I was mainly interested in
 > the correctness aspect. I can do a pair of properly measured gcc
 > builds on the fastest machine next weekend.

On my Kirkwood (1.2GHz QNAP TS-119) the time to do a gcc-4.4 bootstrap
(all default languages) and testsuite run is 87561 seconds with a
vanilla 2.6.32 kernel and 86719 seconds when this patch is applied.
That's a 1% improvement.

Tested-by: Mikael Pettersson <mikpe@it.uu.se>

[CFT:PATCH] Remove a seemingly unnecessary cache flush

[Mike Rapoport]

Hello Russell,

I've tested boot and hackbench on PXA270.

cm-debian:~# cat /proc/cpuinfo
Processor       : XScale-PXA270 rev 7 (v5l)
BogoMIPS        : 311.29
Features        : swp half thumb fastmult edsp iwmmxt
CPU implementer : 0x69
CPU architecture: 5TE
CPU variant     : 0x0
CPU part        : 0x411
CPU revision    : 7

Hardware        : Compulab CM-X2XX
Revision        : 0000
Serial          : 0000000000000000



-- 
Sincerely yours,
Mike.

[CFT:PATCH] Remove a seemingly unnecessary cache flush

[Russell King - ARM Linux]

Could I have some Tested-by: lines for this patch please?

On Mon, Dec 07, 2009 at 10:12:10PM +0000, Russell King - ARM Linux wrote:
> While looking into the possible msync() issue (which turned out to be a
> non-issue - it's covered by clever code), I found that we're flushing
> the same page multiple times.
> 
> Normally, update_mmu_cache() would not be doing anything on architectures
> which don't have a software-loaded TLB.  However, we use this hook for
> two things:
> 
> 1. for our delayed flush_dcache_page().
> 2. to fix up multiple shared write-able mappings of the same page.
> 
> However, as of 8 years ago, I committed this patch (sorry for the
> bkbits URL):
> 
> http://linux.bkbits.net:8080/linux-2.6/?PAGE=patch&REV=3dd7c1f9DypjNd1HyQFAOsA3p7mYig
> 
> What the majority of that patch is doing is adding the user-mapping
> flushing to __flush_dcache_page() - that's fine, and it's explained in
> the changeset comments.
> 
> It also tries to merge the new __flush_dcache_page() code inside
> make_coherent() - make_coherent() is sort-of already doing most of what
> __flush_dcache_page() does, and for good measure it does a final
> flush_cache_page().
> 
> The unused addition of 'dirty' seems to suggest that this extra
> flush_cache_page should have been conditional on that.
> 
> Moreover, this final flush_cache_page() should not be needed - the whole
> "delayed flush_dcache_page" thing only happens when there are no pre-
> existing mappings of the page, and so there should be no user mappings
> to worry about.
> 
> Hence, I believe it is safe to get rid of this - but this patch will
> need some rigorous testing.  My ARM VersatilePB926 still boots without
> this additional patch - but that's not a very good test.  I can't say
> much more than that for the time being.
> 
> Note: for ARMv6 and later, flush_cache_page() is a no-op, so please
> don't bother testing this patch there.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
>  arch/arm/mm/fault-armv.c |    2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mm/fault-armv.c b/arch/arm/mm/fault-armv.c
> index 7296022..666a871 100644
> --- a/arch/arm/mm/fault-armv.c
> +++ b/arch/arm/mm/fault-armv.c
> @@ -127,8 +127,6 @@ make_coherent(struct address_space *mapping, struct vm_area_struct *vma, unsigne
>  	flush_dcache_mmap_unlock(mapping);
>  	if (aliases)
>  		adjust_pte(vma, addr);
> -	else
> -		flush_cache_page(vma, addr, pfn);
>  }
>  
>  /*
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[CFT:PATCH] Remove a seemingly unnecessary cache flush

[Mikael Pettersson]

On Mon, 7 Dec 2009, Russell King - ARM Linux wrote:
 > While looking into the possible msync() issue (which turned out to be a
 > non-issue - it's covered by clever code), I found that we're flushing
 > the same page multiple times.
 > 
 > Normally, update_mmu_cache() would not be doing anything on architectures
 > which don't have a software-loaded TLB.  However, we use this hook for
 > two things:
 > 
 > 1. for our delayed flush_dcache_page().
 > 2. to fix up multiple shared write-able mappings of the same page.
 > 
 > However, as of 8 years ago, I committed this patch (sorry for the
 > bkbits URL):
 > 
 > http://linux.bkbits.net:8080/linux-2.6/?PAGE=patch&REV=3dd7c1f9DypjNd1HyQFAOsA3p7mYig
 > 
 > What the majority of that patch is doing is adding the user-mapping
 > flushing to __flush_dcache_page() - that's fine, and it's explained in
 > the changeset comments.
 > 
 > It also tries to merge the new __flush_dcache_page() code inside
 > make_coherent() - make_coherent() is sort-of already doing most of what
 > __flush_dcache_page() does, and for good measure it does a final
 > flush_cache_page().
 > 
 > The unused addition of 'dirty' seems to suggest that this extra
 > flush_cache_page should have been conditional on that.
 > 
 > Moreover, this final flush_cache_page() should not be needed - the whole
 > "delayed flush_dcache_page" thing only happens when there are no pre-
 > existing mappings of the page, and so there should be no user mappings
 > to worry about.
 > 
 > Hence, I believe it is safe to get rid of this - but this patch will
 > need some rigorous testing.  My ARM VersatilePB926 still boots without
 > this additional patch - but that's not a very good test.  I can't say
 > much more than that for the time being.
 > 
 > Note: for ARMv6 and later, flush_cache_page() is a no-op, so please
 > don't bother testing this patch there.
 > 
 > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
 > ---
 >  arch/arm/mm/fault-armv.c |    2 --
 >  1 files changed, 0 insertions(+), 2 deletions(-)
 > 
 > diff --git a/arch/arm/mm/fault-armv.c b/arch/arm/mm/fault-armv.c
 > index 7296022..666a871 100644
 > --- a/arch/arm/mm/fault-armv.c
 > +++ b/arch/arm/mm/fault-armv.c
 > @@ -127,8 +127,6 @@ make_coherent(struct address_space *mapping, struct vm_area_struct *vma, unsigne
 >  	flush_dcache_mmap_unlock(mapping);
 >  	if (aliases)
 >  		adjust_pte(vma, addr);
 > -	else
 > -		flush_cache_page(vma, addr, pfn);
 >  }
 >  
 >  /*
 > 
 > _______________________________________________
 > linux-arm-kernel mailing list
 > linux-arm-kernel at lists.infradead.org
 > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

What's the status of this patch? I see that it's still not included
in the 2.6.34-rc1 kernel. Did it turn out to be invalid, or was it
just forgotten?

As I reported earlier, it sped up an important use case for me by 1%,
so I've been using it in my ARM kernels for almost 3 months now.

/Mikael

[CFT:PATCH] Remove a seemingly unnecessary cache flush

[Russell King - ARM Linux]

On Tue, Mar 09, 2010 at 04:46:43PM +0100, Mikael Pettersson wrote:
> What's the status of this patch? I see that it's still not included
> in the 2.6.34-rc1 kernel. Did it turn out to be invalid, or was it
> just forgotten?

I was hoping for some tested-by lines before including it, as I
requested on the 18th December.

[CFT:PATCH] Remove a seemingly unnecessary cache flush

[Mikael Pettersson]

Russell King - ARM Linux writes:
 > On Tue, Mar 09, 2010 at 04:46:43PM +0100, Mikael Pettersson wrote:
 > > What's the status of this patch? I see that it's still not included
 > > in the 2.6.34-rc1 kernel. Did it turn out to be invalid, or was it
 > > just forgotten?
 > 
 > I was hoping for some tested-by lines before including it, as I
 > requested on the 18th December.

These report successful tests, but only one (mine) includes a
proper Tested-by line:

http://lists.infradead.org/pipermail/linux-arm-kernel/2009-December/006473.html
http://lists.infradead.org/pipermail/linux-arm-kernel/2009-December/006048.html
http://lists.infradead.org/pipermail/linux-arm-kernel/2009-December/005663.html
http://lists.infradead.org/pipermail/linux-arm-kernel/2009-December/005855.html

Anyway, I'm happy to hear that the patch is still valid, so I'll
continue to apply it locally until it gets merged upstream.

[CFT:PATCH] Remove a seemingly unnecessary cache flush

[Uwe Kleine-König]

Hello Russell,

my machine works fine with your patch.  Tested booting + hackbench.

Best regards
Uwe

root at phyCORE:~ cat /proc/cpuinfo 
Processor	: ARM926EJ-S rev 4 (v5l)
BogoMIPS	: 199.06
Features	: swp half thumb fastmult edsp java 
CPU implementer	: 0x41
CPU architecture: 5TEJ
CPU variant	: 0x0
CPU part	: 0x926
CPU revision	: 4

Hardware	: phyCORE-i.MX27
Revision	: 0000
Serial		: 0000000000000000


-- 
Pengutronix e.K.                              | Uwe Kleine-K?nig            |
Industrial Linux Solutions                    | http://www.pengutronix.de/  |