> This doesn't happen on x86. The processor snoops all transactions
> done by other agents to/from main memory. The processor caches are
> always up to date.
No. My original mail presented two situations in which this assumption is
false.
1. Bank-switched RAM. You want to force a writeback before switching pages.
I _guarantee_ you that the CPU isn't snooping my access to the I/O port
which sets the latch that drives the upper few address bits of the RAM
chips.
2. Flash. A few writes of magic data to magic addresses and a whole erase
block suddenly contains 0xFF. The CPU doesn't notice that either.
What I want is a function like simon_says_flush_page_to_ram(). In this
case, I _do_ know better than the CPU. It is _not_ coherent with these
devices.
I'm actually working on a MIPS box at the moment - the particular problems
with doing it on i386 don't interest me too much. To be honest, I could do
it by sticking asm instructions inside ifdefs in what is otherwise
arch-independent code. I'd rather not do it like that, though.
Surely stuff like that should be exported by the arch-specific code or
include files somehow. Possibly with a #define or function I can use to tell
whether a selective flush is actually available on the current CPU. If it's
not possible to flush the dcache selectively, then the cost of doing a full
flush probably outweighs the benefit¹ of running the flash cached in the
first place. But it should still be possible to do it from arch-independent
code without manually inserting asm instructions to do it.
-- dwmw2¹ The _assumed_ benefit, admittedly. I should get some benchmarks to back up the comment about molasses in arch/cris/drivers/axisflashmap.c
- 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/