Re: [patch] cache flush bug in mm/filemap.c (all kernels >=2.5.30(at least))

[David S. Miller (davem@redhat.com)]

   From: Roman Zippel <zippel@xxxxxxxxxxxxxx>
   Date: Mon, 26 May 2003 15:18:01 +0200 (CEST)
   
   I'd prefer not to do this at driver level at all and rather let the
   user of the data do it.

This is an easy thing to say, but you have to recognize that PIO
based data transfers must retain the EXACT behavior required of
real DMA transfers, which is that a subsequent user mapping of the
data must be able to see the data without an intervening
flush_dcache_page() or similar.

You can STILL optimize this the way you seem to want to.  The
update_mmu_cache() routing exists as a point at which you can
do such deferred situation-based flushing optimizations.

F.e. at ide_insw() time you mark pages as "might_need_flush" with
some bit in page->flags, we even have bits allocated for arch specific
use and we can allocate 1 or 2 more if you need them.  Then at
update_mmu_cache() time you check this bit and act accordingly.

This is exactly the kinds of things I expected platforms to do.
It took a while but even PPC moved all of their flush_icache_page()
stuff into update_mmu_cache() based delayed flush schemes.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/