Messages in this thread | | | From | "David S. Miller" <> | Date | Wed, 27 Jun 2001 17:46:36 -0700 (PDT) | Subject | Re: [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.
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/
| |