:>     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.  
:I disagree.  If a backing object (BO) has OBJ_ONEMAPPING set, and someone
:call vm_map_delete(map, start, end) on an address space that references
:BO directly, then the system will crash and burn because vm_map_delete
:will (incorrectly) free physical pages:
:       ...
:        pmap_remove(map->pmap, s, e);
:        if (object != NULL &&
:            object->ref_count != 1 &&
:            (object->flags & (OBJ_NOSPLIT|OBJ_ONEMAPPING)) == OBJ_ONEMAPPING &&
:            (object->type == OBJT_DEFAULT || object->type == OBJT_SWAP)) {
:                vm_object_collapse(object);
:                vm_object_page_remove(object, offidxstart, offidxend, FALSE);
:               ^^^^^^^^^^^^^^^^^^^^^

    This is in the top-level object, so it isn't a problem.  OBJ_ONEMAPPING
    will be correct.

    If there are problems anywhere, they are going to be in the collapse()
    code..  Either vm_object_collapse() or vm_object_backing_scan()
    (called by vm_object_qcollapse()).

    I think vm_object_collapse() is safe, it will only remove pages from the
    backing object if the reference count is 1, which guarentees that there
    are no shared mappings no matter what the state OBJ_ONEMAPPING.

    vm_object_backing_scan() also appears to be safe... it is either only
    called from vm_object_collapse(), or vm_object_qcollapse().  
    vm_object_qcollapse() also only calls it if the backing object has 
    only one refrence count.

    I think we're safe.  I agree that not having OBJ_ONEMAPPING set properly
    in underlying objects is bad design... but it's a design we inherited
    and it's hard enough making the code work I don't want to introduce new
    bugs fixing something that may not be broken (beyond not being documented

:>     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.
:Umm, it can do this without the OBJ_ONEMAPPING attribute, because
:the ref count on the object == 1.  Note that the code from vm_object_shadow
:doesn't even check OBJ_ONEMAPPING:
:I do care, because I don't want those pages freed by a vm_map_delete.

    I think we're safe.  If you can find a case where vm_map_delete() 
    screws us up, then we have a problem.  I can't find a case.

:>     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.
:Huh?  It's always been the case that when a shadow object is created, 
:its size is equal to the size of the mapping.  This predates the
:existance of OBJ_ONEMAPPING.  vm_map_lookup, where shadow objects
:are normally created on COW faults, has always done:

    Ach, yes you're right.  There's a case I fixed a while back... ah, I
    remember what it was, it was the stack-extension code.  That's what
    I was thinking of.  It has nothing to do with what we are talking
    about now.  Sorry, my mistake!

    I think there are cases where the maps get broken up, though... where
    is it..   Ah, here it is.  The vm_map_split() code.  I think this may
    play a role when you have long fork() chains, but I haven't checked
    for sure.

:>     In this respect, the OBJ_ONEMAPPING optimization is *CRITICAL* to the
:>     scaleability of our VM system.
:It's not critical.  COW worked just fine (performance-wise)
:before OBJ_ONEMAPPING.  John Dyson introduced OBJ_ONEMAPPING
:so that he could free individual pages within an object earlier,
:without waiting for the entire object to be freed.


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

Reply via email to