> 
> Randy Terbush <randy@zyzzyva.com>  wrote:
>  > It's my concern that the attitude that "the PC sucks" prevents
>  > things like bounce buffers and other useful features from being
>  > included in this very clean source tree.
> 
> Actually, I think it's things like "this very clean source tree"
> that keeps things like the hacked bounce buffer patches from being
> included "in this very clean source tree".
> 
It will be very interesting to see an MI scheme be as high in performance
as "existing" schemes.  When NetBSD includes its "MI" scheme, it will be
reviewed by the FreeBSD team, and if it is good enough, WILL be included
in FreeBSD. :-).  It appears that bounce buffers on X86 archs are becoming
less interesting over time now, mostly needed by legacy machines.  A few
years ago, when FreeBSD added them, bounce buffers were more important on
X86s.  The more interesting new applications for bouncing would be new
workstations that need them.  Since NetBSD is fixing the problem now, it
shows that probably the emphasis of NetBSD has been on such workstations.

"Clean" is an interesting word with many meanings -- to me, "clean" means
something that works with little overhead and good scalability.  Clean
also means portable, but what is chosen to be MI or not is a matter
of choice or design by the developers.  How come the pmap code isn't
MI? :-).  Take a look at the ugly asm's that FreeBSD has removed from
the pmap code, and see the significant performance improvements that
have been happening.  When I get a Power PC, a port of the VM system
will go very very quickly (of course borrowing from NetBSD in the
non-VM areas as needed -- there is currently a port in progress anyway.)  It
is all just a matter of project emphasis.

Take a look at the pagefault rate of NetBSD when processes start up
(esp when using shared libs/.text).  That was one of the major things
that we had to fix to have competitive performance with other OSes.
The stuff in FB 2.1 is ancient compared to the stuff today, even though
pagefaults and pmap operations had been greatly diminished since the
4.4Lite(and /2).  FB 2.2-current has even faster fork/exec speed than
FB 2.1. Also, due to the way that the original 4.4Lite VM works, a new
process (or shared lib) starting up can significantly slow down other
processes using the same mapped regions (.text/.data).

Again, definition of clean is not universal, and yes there is cruft in
FreeBSD (note the asms in the pmap code in NetBSD -- and older FreeBSD
code also.)  The reason for the asms was very inefficient VM performance
in the higher layers.  FreeBSD just does not need the pmap asms anymore to keep
performance high.  The FreeBSD bounce scheme was added to solve an
>immediate< problem that a lot of users had.  The original pmap asms were
added to FreeBSD, and then NetBSD to improve performance.  FreeBSD doesn't
need the cruft anymore.  Now, when the NetBSD bounce scheme comes out, we'll
see if it fits our needs, and happily add it if it applies, keeping both our
existing user base happy and being ready to expand to new architectures.

John
dyson@freebsd.org