Messages in this thread | | | Subject | Re: [RFC PATCH] Update the cachetlb.txt file WRT flush_dcache_page and update_mmu_cache | From | Catalin Marinas <> | Date | Tue, 11 May 2010 18:22:34 +0100 |
| |
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@arm.com> 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
| |