Messages in this thread | | | Subject | Re: [patch 00/14] remap_file_pages protection support | From | Lee Schermerhorn <> | Date | Tue, 02 May 2006 13:16:46 -0400 |
| |
On Tue, 2006-05-02 at 13:45 +1000, Nick Piggin wrote: > blaisorblade@yahoo.it wrote: > > > The first idea is to use this for UML - it must create a lot of single page > > mappings, and managing them through separate VMAs is slow. > > I don't know about this. The patches add some complexity, I guess because > we now have vmas which cannot communicate the protectedness of the pages. > Still, nobody was too concerned about nonlinear mappings doing the same > for addressing. But this does seem to add more overhead to the common cases > in the VM :( > > Now I didn't follow the earlier discussions on this much, but let me try > making a few silly comments to get things going again (cc'ed linux-mm). > > I think I would rather this all just folded under VM_NONLINEAR rather than > having this extra MANYPROTS thing, no? (you're already doing that in one > direction). <snip>
One way I've seen this done on other systems is to use something like a prio tree [e.g., see the shared policy support for shmem] for sub-vma protection ranges. Most vmas [I'm guessing here] will have only the original protections or will be reprotected in toto. So, one need only allocate/populate the protection tree when sub-vma protections are requested. Then, one can test protections via the vma, perhaps with access/check macros to hide the existence of the protection tree. Of course, adding a tree-like structure could introduce locking complications/overhead in some paths where we'd rather not [just guessing again]. Might be more overhead than just mucking with the ptes [for UML], but would keep the ptes in sync with the vma's view of "protectedness".
Lee
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |