Thanks for the info. Its good to see a constructive comment between
	the {Free,Net}BSD groups...

	The fundamental difference between Net' & Free' seems to be the Free'
	team are willing to add something in that is not totally The 
	Right Way and work with it gradually, while Net' insists it Must Be
	Right before it goes in.  (Ok, so I'm simplifying :)

	The FreeBSD team will say it gets them there faster, while the
	NetBSD team will say it gets them to the Right Place.

	I'd just like to see everyone being able to work if not together then
	not against each other. (And concentrate on the real job in hand -
	bashing Lin-- oops, sorry, Microsoft :) 

		David

 D.K.Brownlee@city.ac.uk (MIME) +44 171 477 8186  {post,host}master  (abs)
Network Analyst, UCS, City University, Northampton Square, London EC1V 0HB.
 <<< Monochrome - Largest UK Internet BBS - try telnet mono.city.ac.uk >>>

> We did do the VM/buffer cache merge, but I can tell you that I don't think
> there is a good (optimum) way to do it :-).  The problem is with the vastness
> of the change.  On FreeBSD we are taking a step by step approach with a vision
> of where it should go.  The first step that we have taken is to compatibly
> implement it using the buffer cache.  We will probably continue to use the
> buffer cache mechanism, but on a case-by-case basis eliminate it (e.g. UFS),
> except for perhaps meta-data.  Also, LFS probably deserves special treatment.
> It is very tricky to get it working correctly with filesystems with
> blocksizes smaller than a page.  Also, a policy needs to be developed on
> how many dirty buffers or pages are allowed before flushing them.  Of course,
> 64MB or 256MB of dirty buffers can be fairly slow to flush...  FreeBSD
> has a relatively conservative policy on the number of buffers allowed to be
> dirty.
> 
> The biggest side effect of the FreeBSD implementation is that unused
> memory is available for buffer caching, while our old scheme limited the
> cache size to about 2-3MB for a 16MB system.  It is bad to allow the buffer
> cache to compete with the memory in processes.. But we have resolved that
> with a conservative policy that appears to work.
> 
> Other strange effects can occur because of  the large number of VM objects
> that are cached in the FreeBSD implementation.  Various other team members
> and contributors have really helped to shake those problems out.
> 
> The end result of the FreeBSD scheme is a buffer caching scheme that appears
> to have no untoward side-effects, while giving the advantages of coherency
> and dynamic sizing.  It would be excessively difficult to integrate the
> FreeBSD code into NetBSD, because the VM systems have almost totally
> diverged, however there might be some lessons to be learned from the FreeBSD
> experience.
> 
> John
> dyson@root.com
> 
> 
>