lkml.org 
[lkml]   [2003]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] cache flush bug in mm/filemap.c (all kernels >= 2.5.30(at least))
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:35    [W:0.083 / U:0.408 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site