On Tue, 2010-05-11 at 12:31 +0100, FUJITA Tomonori wrote: > On Mon, 10 May 2010 11:16:47 +0100 > Catalin Marinas <catalin.marinas@xxxxxxx> wrote: > > > > I don't think that just replacing sparc64 with IA64 helps much here > > > since we still have the problem that the whole cache handling > > > (architectures, subsystems, file systems) is inconsistent. I think > > > that we need to agree on it first. > > > > Yes, this need to be agreed and hopefully this thread is a starting > > point for such discussion. > > Hopefully, but I'm not sure what we need to agree is clear enough. > > If we invert the meaning of PG_arch_1 (from PG_dcache_dirty to > PG_dcache_clean) like the way IA64 and POWERPC to use the bit to solve > I/D coherency, we can avoid calling flush_dcache_page() at low level > drivers or their subsystems (ide_* macros, libata, > bio_flush_dcache_pages, rq_flush_dcache_pages, etc). Architectures > that need to handle D aliasing and I/D coherence need two bits > respectively (needs another PG_arch_2 bit) to do flushes effectively. The two bits idea was mentioned in the previous threads on cache coherency. So we basically have two main options (IMHO): 1) leave things as they currently are with PG_arch_1 meaning "dirty" and change all low level (PIO) drivers call flush_dcache_page() when they dirty the D-cache. 2) changing the meaning of PG_arch_1 to "clean" and maybe introduce PG_arch_2 as an optimisation but don't force the low level drivers to call flush_dcache_page(). The current cachetlb.txt recommends (1) but not all low-level (PIO) drivers call flush_dcache_page(), hence I/D cache coherency issues at least on ARM. Should we go for (2) as a general recommendation across all architectures that require I/D cache maintenance? Or stick with (1) and modify the low level drivers to call flush_dcache_page (or a PIO API similar to kmap that was already proposed on linux-arch)? Thanks. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html