[lkml]   [2001]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] swapin flush cache bug

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.

David S. Miller
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:55    [W:0.194 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site