On Sat, 15 Apr 2000, Alan Cox wrote:

> >     It is totally legal for OBJ_ONEMAPPING to be set even if the ref_count
> >     is greater then 1.
> Agreed.  OBJ_ONEMAPPING actually means that *each page* within the object
> is mapped at most once.  The object itself may be mapped many times,
> as long as the previous rule isn't violated.  In other words, none
> of the mappings map an overlapping set of pages.

Alright, this makes sense to me.

> >     ...  The ref_count has no bearing on the shareability
> >     of the object any more.  The tests were there before due to all sorts
> >     of crud that had been hacked in in the 2.2.x and 3.x era to get around
> >     serious bugs in the OBJ_ONEMAPPING flag and elsewhere in the VM system.
> > 
> >     Note that the ref_count == 1 test in the vm_object_shadow optimization
> >     should be left intact.  This optimization requires a much stricter set
> >     of tests because we do not want to assume sharability of an object
> >     if someone else (the 'else' being 'someone unknown to us') has a reference
> >     on it, even if OBJ_ONEMAPPING is set.
> > 
> Here's what troubles me about the state of the OBJ_ONEMAPPING management
> code: When we clear the OBJ_ONEMAPPING attribute on an object, we don't
> touch any of its backing objects.  Specifically, we don't guarantee
> that they don't have OBJ_ONEMAPPING set.  I think we should, if only
> because it makes reasoning about the system's behavior a lot easier.
> If we cleared OBJ_ONEMAPPING recursively, then the rationale for
> this assertion would go away.

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?  So, when you
set OBJ_ONEMAPPING, should you check upward recursively to check if
those objects can have OBJ_ONEMAPPING set?  I assume that you mean that
a backing object itself should have OBJ_ONEMAPPING cleared if any of
the children have it cleared.

> Brian, if you'd like to try this, I'll be happy to review it.

I'm going to research the VM a bit more now that you and Matt have gotten
me on track again, and soon wouldn't mind doing that :)

> Alan

 Brian Fundakowski Feldman           \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]                    `------------------------------'

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

Reply via email to