On Sat, Apr 15, 2000 at 06:09:56PM -0400, Brian Fundakowski Feldman wrote:
>
> I'm still trying to understand this: if you know that the object may
> have pages mapped elsewhere, the backing objects recursively inherit
> the assumption that it may have parts mapped elsewhere?
Umm, just to be clear, it's not that the object has pages mapped
elsewhere, it's that one (or more) pages in the object have two or more
mappings. In other words, the same physical page is mapped twice.
It's okay for an object to have multiple mappings (and thus ref_count > 1)
and have OBJ_ONEMAPPING set if all of these mappings map disjoint sets
of pages. (This is what's happening when the assertion gets mistriggered.)
So, OBJ_ONEMAPPING gets cleared whenever it becomes possible for the same
physical page to get mapped twice. (In other words, it happens before
the mapping is actually created, e.g., from vm_map_copy_entry() that gets
called on a fork.)
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.
> ... So, when you
> set OBJ_ONEMAPPING, should you check upward recursively to check if
> those objects can have OBJ_ONEMAPPING set?
No. When you clear OBJ_ONEMAPPING, you should clear OBJ_ONEMAPPING
on all of its backing objects. You can only set OBJ_ONEMAPPING under
limited circumstances where you can prove that no page within an object
has two or more mappings, e.g., the object's ref_count == 1.
> ... I assume that you mean that
> a backing object itself should have OBJ_ONEMAPPING cleared if any of
> the children have it cleared.
>
No. backing object == child.
Stepping back from the details, keep in mind the following: OBJ_ONEMAPPING
is an optimization. If you clear it when it could be set, nothing breaks.
(The worst case is that we don't free up swap space as quickly. An
entire chain of objects has to disappear before we can reclaim the swap.)
On the other hand, if you set OBJ_ONEMAPPING when it shouldn't be set,
you break things badly. (Go back and look at the mailing lists when John
first introduced this code.)
Alan
P.S. This is one area where UVM has the advantage. They have per-page
ref counts in their vm objects, and not just vm object granularity
ref counts. Thus OBJ_ONEMAPPING isn't necessary.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
