On Tue, Jan 08, 2008 at 04:31:03AM +0100, Andi Kleen wrote: > On Tue, Jan 08, 2008 at 03:49:07AM +0100, Nick Piggin wrote: > > On Tue, Jan 08, 2008 at 03:37:46AM +0100, Andi Kleen wrote: > > > > - strongly ordered > > > > - bufferable only * > > > > - device, sharable * > > > > - device, unsharable > > > > - memory, bufferable and cacheable, write through, no write allocate > > > > - memory, bufferable and cacheable, write back, no write allocate > > > > - memory, bufferable and cacheable, write back, write allocate > > > > - implementation defined combinations (eg, selecting "minicache") > > > > - and a set of 16 states to allow the policy of inner and outer levels > > > > of cache to be defined (two bits per level). > > > > > > Do you need all of those in user space? Perhaps you could give > > > the bits different meanings depending on user or kernel space. > > > I think Nick et.al. just need the bits for user space; they won't > > > care about kernel mappings. > > > > Yes correct -- they are only for userspace mappings. Though that includes mmaps > > of /dev/mem and device drivers etc. > > /dev/mem can be always special cased by checking the VMA flags, can't it? That's basically what we do today with COW support for VM_PFNMAP. Once you have that, I don't think there is a huge reason to _also_ use the pte bit for other mappings (because you need to have the VM_PFNMAP support there anyway). For lockless get_user_pages, I don't take mmap_sem, look up any vmas, or even take any page table locks, so it doesn't help there either. (though in the case of lockless gup, architectues that cannot support it can simply revert to the regular gup). - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
