On Sun, 2006-06-04 at 23:23 +0100, Russell King wrote: > I'll add to this statement that the cache flushing on ARM is only > ever required when the page ends up in userspace - if we're reading > a page into the page cache to throw it out via NFS or sendfile then > the cache flush is a complete waste of time. Right .. and this is the scenario. There are two cases where devices kmap a user page into kernel space and then proceed to read from or write to it (flush_dcache_page() is specifically for the latter because the user won't see the data the kernel just wrote unless this happens because kernel and user addresses aren't congruent on parisc). The first case is manufactured data (such as command emulation) and the second is pio data rather than DMA (such as command re-completion or IDE). > In this respect, I continue to believe that the way ARM (in principle) > does flush_dcache_page() is what is required here - if the page has > not been mapped into userspace, it merely marks the page as containing > dirty cache lines, and the resulting cache maintainence will only > happen when (and if) the page really does get mapped into userspace. For this particular scenario, the page is almost always mapped initially in user space because the user is requesting the I/O to a given userspace address ... get_user_pages() ensures that it is allocated and flushed before being passed to IDE or SCSI. The problem on parisc, however, is not that userspace doesn't see the page as dirty, it's that we've dirtied the page through the kernel mappings, so userspace itself cannot possibly see the change until the cache over the kernel address is flushed (the userspace and kernel space addresses are not congruent in our cache scheme, so get separate cache lines). James - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
