On Fri, 2011-01-07 at 13:53 -0500, Trond Myklebust wrote: > There is already code in the SUNRPC layer that calls flush_dcache_page() > after writing (although as Russell pointed out earlier, that is > apparently a no-op for non-page cache pages such as these). Actually (and possibly fortunately) none of our flush_dcache_page() implementations do this (check for an actual non page cache page and nop if they find one). Although, they may according to the docs which say that flush_dcache_page() is only called on page cache pages. But it's definitely using the API outside its documented scope. We have lots of places in the VFS where we don't call flush_dcache_page() even after altering a kernel page (even in the page cache) if we know the page will never be mapped to userspace. The assumption here is that the kernel never sets up non-user aliases of these pages, so not doing the flushing is an optimisation since we only access them through the kernel address space. Of course, setting up vmap areas of these pages within the kernel violates this assumption. > > This is why you really really really generally don't want to have > > aliasing. Purely virtual caches are pure crap. Really. > > Well, it looks as if NOMMU is giving us problems due to the lack of a > vm_map_ram() (see https://bugzilla.kernel.org/show_bug.cgi?id=26262). > > I'd still like to keep the existing code for those architectures that > don't have problems, since that allows us to send 32k READDIR requests > instead of being limited to 4k. For large directories, that is a clear > win. > For the NOMMU case we will just go back to using a single page for > storage (and 4k READDIR requests only). Should I just do the same for > architectures like ARM and PARISC? Well, that would include any VI architecture (like SPARC and others) as well. However, I think we can just make the invalidate_kernel_vmap_range() work. James -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
