Re: 2.6.13-rc3: cache flush missing from somewhere

["David S. Miller" <davem@davemloft.net>]

From: Catalin Marinas <catalin.marinas@arm.com>
Date: Mon, 01 Aug 2005 13:24:04 +0100

> "David S. Miller" <davem@davemloft.net> wrote:
> > If not, you cannot use the lazy dcache flushing method, and in fact
> > you must broadcast the flush on all processors.
> 
> Why wouldn't the lazy dcache flushing method work? My understanding is
> that if there is no user mapping for a given page, there's no reason
> to flush the dcache and just postpone it until the page is faulted
> in. When the page fault occurs the dcache should be flushed (on one
> CPU is enough) and the icache invalidated on all the CPUs.

The "lazy dcache flushing" he mentioned only flushes on the
processor where the store occurred, not on any other cpus.

He took the sparc64 code which, at the time of the flush_dcache_page()
call, stores the current cpu number in the page->flags and sets a
bit indicating a flush is needed.  When some condition occurs
requiring the delayed flush to occur, we look at the cpu number
in the page and ask that specific cpu to do the flush.

This works perfectly for what sparc64 is trying to do, which is deal
with bad aliasing in a virtually indexed D-cache where only the cpu
who does the store has to do any flushing, but that won't work for
this ARM SMP case at all.

I've seen implementations where the I-cache does not snoop local cpu
stores, but I've never seen one where other cpus do not snoop such
stores.  You _HAVE_ to implement handling of I-cache update on L2
cache line changes to handle updates from devices doing DMA, so why
in the world special case stores done by other cpus?

It almost sounds impossible to implement this and have the I-cache
be coherent wrt. DMA transactions.

Do you have to flush the whole I-cache every time some device DMAs
a page into memory, before you can execute instructions out of it?
-
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/