Re: [PATCH] swapin flush cache bug

[David S. Miller]

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
[e-mail]