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

> 
> >Frankly, the use of the VM object inheritance scheme vs. other schemes 
> >is a matter of opinion.  At the end of the day, the difference will be 
> >negligible, because that isn't where the (performance or bug) problems 
> >have been in FreeBSD for years.
> 
> hmmm.   well, in browsing the FreeBSD VM related CVS commit logs it
> seems to me that a significant (and impressive!) amount of effort 
> has gone into debugging and fixing object management code over the 
> years.    and i've also seen both NetBSD and OpenBSD struggle with 
> trying to sort out the object collapse issues properly.  it sure
> seems painful to me.   if the difference in performance is going to
> be negligible, then why suffer?
>
The problem with the object management code has been a TOTAL lack of
understanding.  There is absolutely no documentation on the technique
(I believe that the MACH people simply ignored it.)  Once the object
mgmt is understood (and that is akin to the issue of understanding
a compilers language and code generation, from source code), it becomes
quite trivial.  (I believe that the MACH people also had a "defer
everything as long as possible" religion, which is as wrong as any.)

The only reason that we haven't done documentation, is due to lack of
person-power.  There are numerous FreeBSD people who understand the
code supurbly now.  I also have a resource from work that is now
available for creating a paper with me.

The object mgmt is complex only due to a lack of understanding.  I don't
know how to explain it, and indeed it is different that previous practice.
The good news is, that it has few of the disadvantages that have been
alledged.  It isn't perfect, but is also amazingly flexible.

If one wants to use an approach previously used, then the documentation
comes for free (almost.)  There are architectural inflexibilities on the
SVR4 scheme, that might make some epsilon difference in LL performance
indeed, but when the VM code needs to be fast (due to upper level usage
of the code), it isn't.  I have never seen an SVR4 system that can
perform under any kind of load.

Maybe I am the only person that *fully* (more than supurbly) understands
the FreeBSD code, and it is my fault.  It is different from everything
else, and should be documented.  Once done, I think that there will be
alot of "oh, that's how it works, geesh, it *is* simple" :-)).  If it
wasn't so simple, I couldn't understand it :-).

John