Jonathan Stone said:
> 
> Amdahl's Law laves plenty of room for skepticism. Whatever it is that
> FreeBSD is doing to get a 3X speedup on compiles, it must be taking
> 75% of the total wall time on NetBSD.
> 
> That's a staggering difference for a kernel change which, allegedly,
> doesn't involve heavy paging.  What kind of application (which isn't
> thrashing the VM system) is spending 75% of its time in something
> fixed by a merged block/buffer cache?
>
It is actually reasonable considering the total dearth of
disk seeks when using FreeBSD as the build engine.

Disks are a terrible performance problem when working with huge
numbers of files.  If your "make depend" sucks in the entire tree,
and you have the appropriate disk policies, then the observed
FreeBSD behavior becomes reasonable.

I don't think that any of this is based upon LL performance,
page fault times, COW optimizations, paging algorithms.  The
majority of it is disk cache policy, and it really does make
a mondo difference.

On a 256M machine, FreeBSD has an effective disk cache of
between 8M and 256M :-).  The cache mgmt algorithms are
very carefully tuned to minimize I/O costs globally (at perhaps
sometimes excessive CPU cost.)  However, the system as
as whole is almost totally self-tuning, except for the
largest configurations.

There are other things also:  I don't know if our async
works better than yours.  I don't know if our VM code takes
negative time :-).  I have not analyised it carefully, because
I am not the one doing system builds, and don't have time
to sit around, working on NetBSD optimization issues.

Don't assume that just because I am saying something, that
it is something "good" about our VM code.  There are alot
of performance issues that are very difficult to ponder.

-- 
John                  | Never try to teach a pig to sing,
dyson@freebsd.org     | it just makes you look stupid,
jdyson@nc.com         | and it irritates the pig.