On Thu, Jan 25, 2001 at 10:12:22AM -0800, Greywolf wrote:

 > Curiously, regarding reference counts, is there a reason the pages don't
 > have them?  (Keep in mind that my kernel programming knowledge is pretty
 > rudimentary at best -- I never finished my DS courses due to jobs taking
 > precedence.)

Well, they don't really need reference counts.

 > When you're cycling through the pages with the sweeps, I'm assuming
 > you'd be dereferencing pointers to pages (I don't think there's
 > any other way to do it).  Why not have another value on the page, or
 > in the page-node pointer which describes a reference count?

Pages that are being cycled through are explicitly on a scanning queue.
When the page is tossed, it is taken off the scanning queue it's currently
on.  The various things that reference the pages themselves have reference
counts, and when one of those things goes away (an "anon" or a "uobj"), it
checks to see if there is a reference to the page by the other kind of
object, and if not, then takes the appropriate freeing action.

So, they do have a way to track references -- but it takes the form of
two pointers in the vm_page_t -- one that points to an "anon" and one
that points to a "uobj".

 > ...so this then becomes a question of avoiding a resource deadlock
 > of sorts, is that right?  That makes sense.

Err... not really.  But our VM system has various things that allow
applications to provide hints about memory access patterns, and you'd
like to be able to use those hints to make intelligent decisions about
when a page is no longer in use (thus making better use of the available
memory resources).

 > Let me ask if I understand this correctly:  Our first VM model didn't drop
 > pages from core until something else needed the memory (or until it was
 > explicitly freed), i.e. the sweep didn't start until it absolutely had to.  

Err... that's not quite true ... pages could be freed at various times in
the Mach VM system.

 > Then we ripped out the Mach VM and went with what seemed to be a Lite/VM
 > kind of deal where it wasn't Mach, it wasn't BSD 4.3 and it wasn't UBC/UVM.

Err ... the original NetBSD VM system was based on the CSRG port of the Mach
VM system to BSD.

 > Now we're at UVM/UBC, and we want to invalidate pages which have timed
 > out, but we want the timeouts variable; i.e. a page linked to an open
 > file should stay in core longer but not indefinitely if not touched,
 > whereas a page linked to recent anonymous reference but no longer referenced
 > should be invalidated immediately (more or less), and subsequently freed
 > (or at least moved down the chain if we're doing LRU).

Err.. the Mach VM system also had a mechanism to "time out" pages.  In
fact, UVM's mechanism is very much like Mach VM's, but for various reasons,
the page scanning algorithm used by UVM isn't quite as efficient as Mach VM's
in this case.

But we can fix that :-)

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