On Sun, 2010-01-03 at 08:27 +1100, Benjamin Herrenschmidt wrote: > On Thu, 2009-12-24 at 05:39 -0700, Matthew Wilcox wrote: > > > > invalidates the processor cache for a given virtual address range > > in the vmap area. This API addresses the problem that the processor > > may have performed speculative reads into its cache of the vmapped > > area while I/O was occurring to the underlying physical pages. > > > > Signed-off-by: Matthew Wilcox <willy@xxxxxxxxxxxxxxx> > > Interestingly, our DMA APIs in this regard are sub-optimal as they > should provide 3 hooks, not 2. > > Flush is good for ensuring dirty lines have been pushed out before an > outgoing DMA. > > But for incoming DMA it would be nice to properly split the 2 calls that > may be needed on some archs, one before, one after the transfer. Sure, > invalidate twice will "work" but the f will also be sub-optimal on some > platforms depending on whether the platform is known to be able or not > to speculatively load cache lines etc... > > Maybe just a "before" vs. "after" argument ? > > Also, the proposal goes contrary to most of our DMA APIs which don't > actually expose the details of invalidate vs. flush but instead expose > the direction of the transfer (both lack the above subtlety though). > > Thoughts ? Well, that's the result of the email thread. XFS is poking deeply into architectural issues by trying to do I/O on a vmap area. I thought the consensus was that if xfs wants to do that then it takes complete responsibility for coherence rather than trying to hide it in a block API. James -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
