On Thu, Nov 20, 2003 at 09:44:22AM +0100, Paul Kranenburg wrote:
> Since the introduction of UBC, the tasks left to do for the original buffer
> cache system are much reduced and also have changed in pattern. The
> buffer sizes requested are mostly determined by the block size parameters
> of the file systems using the cache for metadata. On my ffsv1 system,
> the sizes range from 1K to 8K.

Am I reading your patch wrong, though, or does it in fact still have a
minimum allocation size of a page?  On systems like the CVS server, which
suffer terribly from our current implementation, that will still not win
as much as we could -- most of the buffer cache on those systems is taken
up by directories that are less than a page in size (often single frags).

Allocating less than a page was the reason I was attacking this using
malloc and realloc instead of a private allocator.  Is there a real
performance benefit to not using malloc, given that you're still using
kernel_map?

I think it's great that you're working on this.  I had something mostly
working a few days after the last use of pagemove() in the filesystems 
died, but then got highly distracted.  One thing I'd caution against would
be eliminating the use of the AGE list without careful measurement on a
number of different systems; it implements a pseudo-generational behaviour
that is not strict LRU and may perform better for some workloads.

Thor