Date: Sat, 15 Apr 2000 20:13:20 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Alan Cox <alc@cs.rice.edu> Cc: Brian Fundakowski Feldman <green@FreeBSD.ORG>, current@FreeBSD.ORG Subject: Re: panic: vm_object_shadow: source object has OBJ_ONEMAPPING set. Message-ID: <200004160313.UAA82143@apollo.backplane.com> References: <20000415140945.B3462@cs.rice.edu> <Pine.BSF.4.21.0004151801140.17351-100000@green.dyndns.org> <20000415185718.E3462@cs.rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
:Here's what I worry about: We only clear OBJ_ONEMAPPING on the top-level
:object, and none of its backing objects. Nothing guarantees that these
:backing objects have OBJ_ONEMAPPING cleared. The page that we're "double"
:mapping may, however, reside in one of its backing objects. This is
:bad.
I don't think this is an issue. The only double-mapped pages we care
about are those at the top-level (vm_object's connected directly to a
vm_map_entry). This is because these are the only pages effected by
write-faults and copy-on-write issues.
For example, if you dirty a page that is mapped privately the system must
copy-on-write the page. More importantly, if you fork() and either parent
or child dirties what is now a shared page, they need to copy on write
and the other process cannot see that change. OBJ_ONEMAPPING is an
optimization that allows a process to dirty an anonymous (not vnode-backed)
page without doing a copy-on-write in the case where that process is
the ONLY process mapping the page.
Copy-on-write is an issue that only effects the top level object. So
we shouldn't care whether OBJ_ONEMAPPING is set or cleared in deeper
objects.
Copying a page that was previously shared is an expensive operation not
only in having to do the copy, but also in having to split the vm_map_entry
and create a new holding vm_object to hold the copy. This new object must
have OBJ_ONEMAPPING set so that when pages are dirtied around it, it can
be pre-pended or post-pended with the new pages rather then have to create
a new vm_object (and thus not be able to coalesce the associated
vm_map_entry structures) every time we take a copy-on-write fault.
In this respect, the OBJ_ONEMAPPING optimization is *CRITICAL* to the
scaleability of our VM system.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004160313.UAA82143>