:> 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
well).
:> 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.
:
:Alan
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
