On Sat, Mar 06, 2010 at 11:56:41AM +0100, Wolfgang Mües wrote: > > 3. A page may be read in response to an application issuing a read(2) call. > > - the data is read from the kernel mapping, and isn't mapped into a > > userspace address. > > > > So, in case (3), flushing the I and D caches could be completely wasteful > But how do you AVOID the writeback of the data cache in (3)? > IMHO, the dirty data is in the cache, and the cache will writeback this data > on its own. You don't avoid the writeback - you avoid explicitly causing the writeback _and_ having to wait for it. If you're writing data into a page (pio) which you then access via that same mapping (via read(2)), it is totally pointless to sit in a loop asking the cache to write the data back to memory. The point when you need this data written back to memory is the point where you start to create mappings which may alias with the existing mapping. Up until that point, the hardware itself can deal with the writebacks when it decides it's a good time to do so. Also, cache replaacement policies may not decide to immediately re-use the cache lines you've just flushed - which means that by forcing them to be written back, you're just increasing the overall latency of the system. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
