Subject: Re: UBC status
To: None <eeh@netbsd.org>
From: Neil A. Carson <neil@causality.com>
List: tech-kern
Date: 09/26/1999 11:14:56
"Eduardo E. Horvath" wrote:

> [Description of pageout issues deleted]

> There are two different issues here: handling dirty pages and allocating
> clean pages for new buffers.
> 
> There are many solutions for problems caused by dirty buffers and most are
> not that complex.

OK, if you say so sir---but a lot of people still seem to handle it
wrongly!!! And I would also suggest that maybe allocation of clean
buffers is partially a function of this...

> Does FreeBSD have a limit on page allocations?

I would guess (ie I am factually inaccurate here) that the overall
metric is to control the size of the cache vs. 'traditional VM' stuff;
and then within that, the allocations for new buffer pages would be on a
similar basis as in the traditional BSD kernels (try and fish one out,
if there isn't one, blow the whole lot of dirty stuff out). Because the
amount of dirty data is kept small, this daft writeout policy probably
isn't painful at all.

I think that NetBSD could be successful continuing along such a path,
but with more sensible trickled writeout. Rather, why instead of taking
the route of running a daemon to flush the whole thing every 'X,' just
have a thread continually monitoring the IO load and---if
idle---clustering and writing?

Will the buffer cache still be kept for metadata?

Re page allocation, one of the things FreeBSD did was to not have the VM
and cache competing agressively unlike Linux (and maybe Solaris). I
think somewhere around on the 'net is an overview of the VM and the
lists it keeps.

I think NT's working set trimming is daft and shouldn't even be
considered---something that sounds cool in thought but doesn't work at
all well in practice.

	Neil