Simon Burge said:
> 
> So, conceivably, you may be able to get something similar with NetBSD
> by setting the BUFPAGES option (ie, the size of the byuffer cache) to a
> size that equates to say 200MB on a 256MB RAM machine?  Obviously this
> is no where near as useful in day-to-day life as a merged VM/buffer
> cache setup, but probably less effort than most vendors go to to get
> good SPEC numbers...
> 
Possibly you could improve things (and perhaps in some cases make them better
than FreeBSD -- I really don't know), however the downsides (and I don't know
how significant they are) would include:

	1)	Fixed allocation sizes for VM and buffer caching (the NetBSD
		split caches are seperate, with some resolution mechanisms to
		make them almost coherent.)  With fixed sizes, there is sometimes
		less efficiency (I don't know how much, but it IS there) than the
		FreeBSD scheme.  Other schemes can miscalculate or have other
		problems with the size allocations.

	2)	No control of dirty buffer cache size.  This is part of the
		Linux and SVR4 flushing brokenness, and one reason why
		they are lousy under load.  Deferring lots and lots of
		writes is not always very wise for performance (except
		in the case of temp files).  Some write deferral is a good
		thing, too much is "too much of a good thing."

	3)	Lots of KVA space would be used.  Buffers take lots of KVA
		space, but for example, FreeBSD doesn't use KVA space for the
		vast majority of it's caching.  There is some mapping cost,
		but that remapping is theoretically optional, when KVA space
		is cheap.  If remapping is very expensive, and KVA space is
		expensive, then we have a delimma :-).

It would *certainly* help by increasing BUFPAGES (and/or NBUFS).  I don't
know how big you would really want to make them, without other problems
appearing.

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