> > What I think is a shame is
> > that John Dyson et. al. have put in a lot of hard work with FreeBSD
> > that is going to be duplicated (albeit in a NetBSD way - whatever that
> > is).
> 
> I don't think we should 'just reintegrate' the FreeBSD stuff; the VM system
> is too important to do that without maybe understanding the details of
> John Dyson's implementation. In a recent message Gordon Ross indicated that
> he had done some research into VM designs, and from his words gather that
> he was inclined to go for the SVR4 approach (at least, with regard
> to the VOP_{GET,PUT}PAGE interface). I've done some looking as well, and
> do think this is the best way to go. How this should be integrated is
> another thing. Sometimes, when looking at the VM code, I wonder if only
>...

I used to maintain SVR4 for a very large vendor (guess who!!!), and I
would suggest reviewing the SVR4 approach very carefully -- and stay
away from it.  SVR4 had a way of making a machine that is faster than
a Pentium 133 look like a 486/66 in certain situations.  That is the
reason that we took a *slightly* different approach.

The GETPAGE/PUTPAGE interface in SVR4 is so severly broken, and so
inefficient that I would not even consider using that approach unless
I was desperate for ideas.  I had nothing but disappointed customers
using SVR4 on those big-ticket machines on high-profile applications.
I WOULD suggest strongly taking a PRACTICAL approach to the design with
a "new look" as opposed to accepting the SVR4 approach as a good example.
Too bad I did not have time to redo the SVR4 stuff :-(.

The GETPAGE/PUTPAGE interface and design on FreeBSD is *very* efficient.  Also
SVR4 has such pathetically slow paging (both paging-in and paging-out) that
I *definitely* would not use that as a model -- unless I wasn't concerned
about my OSes performance.  It was so much fun to benchmark both real
applications and "benchmarks" on a MIPS R4400 and compare it to a 486/66
and see the 486 on FreeBSD cream a MIPS machine running an unnamed version
of SVR4 (of course for VM intensive things only :-)).

It appeared to me that SVR4 VM code was written by people that thought that
they could "do it better", but when we had people migrate from SVR3 to
SVR4, they would generally see a performance hit of 10%-50%!!!  (note that
the SVR3 had ffs, etc -- so the difference was mostly the VM system and the
shared library method...)  Much of the performance hit was measured by multiple
groups to be VM related (paging, buffer cache, shared lib, memory policy.)

Good Luck -- not that the FreeBSD stuff is perfect, but is going through
an evolution, and some pretty amazing things are happening already.

John
dyson@freebsd.org