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

[Roman Zippel]

Hi,

On Mon, 26 May 2003, David S. Miller wrote:

>    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.

I thought about this before, but I don't think there is much to optimize. 
The PG_arch_1 bit is the only optimization which makes sense and setting 
it by default to dirty, makes it a lot easier for PIO drivers. PIO 
transfers are really the smallest problem as drivers write only into not 
uptodate and so not mapped pages. We have to be more careful with other 
writes, that they always call flush_dcache_page().
The point I don't like about update_mmu_cache() is that it's called 
_after_ set_pte(). Practically it's maybe not a problem right now, but 
the cache synchronization should happen before set_pte().

bye, Roman