[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Chuck Silvers <chuq%chuq.com@localhost> 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).
> > 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.
Main Index |
Thread Index |