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
