Hi, On Tue, Nov 02, 2010 at 08:58:14AM +0000, Mindaugas Rasiukevicius wrote: > Chuck Silvers <c...@chuq.com> wrote: > > > > - in getpages, rather than allocating a page of zeros for each file, > > > > it would be better to use the same page of zeroes that mem.c uses. > > > > if multiple subsystems need a page of zeroes, then I think that > > > > UVM should provide this functionality rather than duplicating > > > > that all over the place. if you don't want to update all the > > > > copies of mem.c, that's fine, but please put this in UVM instead of > > > > genfs. > > > > > > I made it per-vnode, because If you share a single physical zero'ed > > > page, when a vnode is putpage'ed, it invalidates all mappings in > > > other vnodes pointing to the zero page in a pmap. Doesn't this > > > sound strange? > > > > I think you're misunderstanding something. for operations like > > msync(), putpage is called on the object in the UVM map entry, > > which would never be the object owning the global page of zeroes. > > from the pagedaemon, putpage is called on a page's object, > > but if the page replacement policy decides to reclaim the page > > of zeroes then invalidating all the mappings is necessary. > > if what you describe would actually happen, then yes, > > I would find it strange. > > FYI: In rmind-uvmplock branch, all MD mem.c are replaced with a single MI > driver, which provides zero page. So that can be easily moved to UVM (and > some day.. in the longer term, we should have a page for each NUMA node).
The difference is, mem.c and others use their zero page from kernel. In XIP it's only for vnodes. I'm not sure how much per-CPU zero page helps XIP. Anyway, I think my per-vnode approach is not terribly bad. Let's improve this later. BTW, can't you merge your mem.c changes first? Masao > > > > Another reason is that by having a vm_page with a uvm_object as > > > its parent, fault handler doesn't need to know anything about the > > > special zero'ed page. > > > > the fault handler wouldn't need to know about the page of zeroes, > > why do you think it would? it does need to be aware that the pages > > returned by getpages may not be owned by the object that getpages > > is called with, but it needs to handle that regardless, for layered > > file systems. > > Lock sharing among UVM objects (for layered file systems and tmpfs) should > bring some simplifications here, I think. > > -- > Mindaugas -- Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635