My turn!

There is a whole list of assorted "things to do" concerning the VM system
out in /sys/vm/TODO in the Lite and Lite-2 releases.  Here is what I would
classify as the biggies:

1. Coherency with the IO system.

This one has been beaten to death already, but I'll flog it a little more.
Two approaches have been considered here: you can make the VM system use the
filesystem (vnode) interface to do IO making the buffer cache the One True
Cache.  This is what SunOS and presumably SVR4 do and was the direction
CSRG was leaning at one time.  One feature/bug of this approach is that all
backing store must be modeled as files in some filesystem.  Fine for mapping
files and even devices but maybe not as obvious for swap space (i.e.,
``anonymous'' VM regions become files in a swap file system).  Some say
this approach is elegant, other say it is contrived.  The other approach is
to have the filesystem use the VM system to do IO (e.g., via pagers) thus
caching in the VM system (vm_objects).  This is what FreeBSD did I believe.
This approach makes it easier to plop the system down on top of a micro-
kernel since most micro-kernels support some notion of VM but not filesystems.

2. Enforces no limits.

The current system makes no attempt to monitor or restrict how much virtual
memory has been allocated.  Chris eluded to this.  As a result you can easily
thrash/deadlock/crash.  I don't think you want to return to the old 4.3
strategy of pre-allocating swap, this is overly restrictive.

3. Page in/out done page at a time.

This is clustering of pageouts and pre-paging for pagein.  4K or 8K is seldom
the optimal IO size for most modern disks :-)  Late in the game I made the
pager interface support multiple pages and did a quicky hack to the pageout
daemon to do clustered pageout.  Clustered pageout helped some, but pagein is
more important (and harder policy-wise).

4. No bulk pageout (i.e., ``swapping'')

Arguably, this is not necessary but in practice it seems to help a lot
under extreme memory pressure.  Swapping is really just a more aggressive
form of clustered pageout.

5. Page replacement daemon sucks.

Going from the 4.3 pageout daemon to the old Mach daemon was a big step
backward.  Much of this may really be the impact of page-at-a-time cleaning
in the Mach version.  In fairness, the current Mach daemon is much different
and its job is complicated enormously by the existence of (potentially
unreliable) external pagers.


As far as I know, the FreeBSD VM system addresses all of these.  How much
better it is, I really don't know.  But that brings me to my next point...

I agree with Andrew Cagney that, unless there is some compelling *technical*
reason, you should just use the FreeBSD VM.  I don't mean just look at it
and learn from it, I mean drop the sucker in and compile it!  Here is what
I would consider ``compelling'' reasons not to do so:

1. It has severe portability problems.  I have no strong reason to believe
   this is the case, though, for example, I have heard of an optimization
   that pre-loads page table entries-- not very meaningful to me and my
   small, software-loaded TLB.  As long as these things are below the MI/MD
   line that is ok.  Anyway, hopefully we can avoid going back to portability
   meaning "make it look like a VAX" (though this seems to be the Linux
   approach (s/VAX/x86/)).

2. You aspire to do something other than make the existing mmap interface
   better (fast, efficient, robust, etc.).  If what your users want is a
   fast BSD-as-we-know-it system then why waste your time re-inventing the
   wheel?  Take advantage of the FreeBSD work and spend time on other things
   like MP support.  However, if you are going to dip your wick in the
   VM buzzword pool (e.g., distributed shared memory, page coloring,
   multiple page sizes, remote memory paging, application controlled paging
   policy/mechanism, separate physical memory pools, persistent virtual
   memory, protection domains, single address space, shared address spaces, 
   andonandonandon) then FreeBSD is probably not the place to start.  I
   don't know what the goals for NetBSD are in this regard.

It may seem rather brazen or maybe naive for me to suggest using the FreeBSD
VM without having looked at it much and I admit to having an ulterior motive:
trying to move the two systems closer together.

Oh well, all this advise is worth what you paid for it...
And of course consider the source, I am the one who left you with the VM
system you have today!

Good Luck,
Mike