Chuck:

One more thing -- I am putting this at the beginning of the
message to make this STAND-OUT as much as possible.  I think that
you are doing good work, and any criticism of a position taken
or code written should not be inferred as criticism of your
work.  The UVM stuff is interesting (and I have had the ability
to see it for much longer than it has been publically available,
but I didn't want anyone to violate confidientiality), and
valuable.

I haven't had time to thoroughly study the UVM stuff, but congrats
on a project that I know looks much easier than it really is.  VM
is a difficult thing to start to understand, and once you really
do understand the issues, it becomes difficult to accept that others
cannot "see how obvious things are", and non-VM people seem to totally
misunderstand it.

I believe that while VM has major performance ramifications on an OS,
it is also ignored.  NT is slow partially due to VM issues, SVR4 can't
handle loads due to VM and filesystem caching issues, Linux cannot
handle loads due to VM and filesystem caching issues.  Things go
on and on.  Once you work out the "memory policy issues" that are
highest layer of the VM code itself (and probably the most totally
misunderstood part of the code), you'll understand (and you might
already understand) how lame the competition is :-).

After looking at (and solving) the policy issues, then the scalability
issues become interesting.  That is also tricky (but mostly an issue
of proper data structure design.)

When you get here, then repeat the above steps again and again,
relentlessly.

Good luck, and recognise that I believe that this is a vastly
underresearched field.  Documentation tends to dry up after
LRU is mentioned (LRU management policies do work well, 
unless you use them. :-)).  There is good research on
database caching design, almost applicable to VM and VFS.
Note also that there is an IBM patent on a reasonable page
management scheme.  FreeBSD has been doing something more
comprehensive, but the IBM scheme (which FreeBSD's predates),
is an interesting start.  It was amazing to see that they
at least almost seemed to understand what to do.  (and in
fact, their stuff might perform as well as or better than
ours, due to simplification, but I haven't coded it, because
of the wasted effort on my part.)  I don't like to waste
my time coding something that I cannot use :-).

Again, good luck!!!  If I cross over from criticising of
ideas to criticising of work or persons, let me know asap,
so I can correct it...

John


> > 
> > >Collapse operations happen very efficiently on FreeBSD, 
> > 
> > because you have elminated the vm_object_collapse calls in vm_fault
> > and vm_object_page_clean?
> >
> Because I have eliminated the need for the collapse in VM fault, and
> there is a special page collapse operation in VM fault.  That is where
> the extra page is (mostly) eliminated.  That did make a very positive
> performance improvement under load.
>