: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

    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

    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.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to