Stephen C. Tweedie writes:
> I really want somebody who has worked on weird caching architectures
> to look at it too, but I don't see that the new code works well.
> First, don't we want to do a flush_page_to_ram() *before* starting the
> swap IO? There's no point dma'ing the swap page to ram if old, dirty
> cache data is then going to be written back on top of that.
>
> Secondly, the flushing of icache/dcache only needs to be done by the
> time we come to use the page, so can be performed any time, before or
> after the IO. We're not going to be accessing the page during IO so
> if we flush first we won't risk having stale cache data by the time
> the IO completes.
>
> So, why not just do the flushing before the IO? Adding an async trap
> to flush the page after swap IO seems the wrong approach: this should
> be possible to fix synchronously.
People are totally confusing two completely seperate issues here.
Flushing for I/O <--> CPU coherency.
Flushing for CPU <--> CPU coherency.
flush_page_to_ram and flush_dcache_page are _ONLY_ for the CPU<-->CPU
coherency issues, not for I/O<-->CPU issues.
The I/O<-->CPU issues need to be handled elsewhere, for example in the
PCI dma mapping interface implementation.
Later,
David S. Miller
davem@redhat.com
-
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/
This archive was generated by hypermail 2b29 : Sat Jun 30 2001 - 21:00:18 EST