On Thu, Jan 25, 2001 at 08:10:36AM +0000, Charles M. Hannum wrote:

 > False.  The faults and/or system calls that cause the deactivates are
 > asynchronous WRT the pagedaemon, and can (will?) easily cause the
 > pages to get paged out more often.  (Note that, since the inactive
 > scan happens first, so this is *particularly* like -- e.g. if the one
 > process then went and allocated another page, implicitly kicking the
 > pagedaemon.)  There is a really trivial test case that causes this to
 > behave very, very badly.

Fair enough -- another option would simply be to clear_reference the
page, and leave it on the active list.  Then, even if the pagedaemon
runs "soon", then it won't matter -- it will be deactivated (which
doesn't unmap the pages in my patch, allowing it to be referenced)
and possibly reactivated later if there are other users.

 > That's true, but the object holding the page (e.g. the anon) does have
 > a reference count that could potentially be used.

Using the reference count on the object is problematic -- you have to
actually check two reference counts (uobj *and* anon), and also deal with
the SEQUENTIAL case where the file may still be open (and may be open for
some time), thus the uobj's reference count isn't going to drop to 0 for
the duration, yet you want the pages to get out of core.

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>