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.)

Sorry if I'm being too much of an internals neophyte -- I'm trying to
pick up on some of this stuff, but let me see if I have this right.

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?

Or would that be a) inefficient and/or b) inaccurate?  (I seem to
remember reading somewhere that a pure reference count GC can leak,
or be raced upon, or somehow else not work properly (and page reclamation
is just the OS term for Garbage Collection, IIUC)...)

Just curious.

# 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.

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

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.  
This made for good performance as long as your activity never exceeded the
limits of physical memory, then it would enter thrash mode.  At least for me
it performed great until I had to start paging, and then the performance
went down the tubes. (I never had to start paging until I was building a
kernel.  If I was just running an X session with some xterms and maybe an
IRC or ftp, my paging activity was nil up until about 1.3 or so.  Either
that or the stats on the swap space were incorrect.)

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.
I'm not quite sure of the mechanics of it, but the performance was smoother,
if slower.  I think that was when the standard invalidate-reclaim sweep
started and ran regardless.

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).

I'm totally aware I may be way off my mark; please bear with me.

				--*greywolf;
--
Microshaft:  Where do you want to crash today?