On Nov 20, 2003, at 9:58 AM, Thor Lancelot Simon wrote:

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

I think what we could do here is have pools that would provide 1K and 
2K buffers (and maybe 4K and 8K if the page size is larger than that), 
and then use uvm_km_alloc() for everything else.

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

The benefit is not a performance benefit.  kernel_map does not have the 
same constraints on it that kmem_map does.  kmem_map is the one used by 
malloc(), and since its size is fixed at boot time, we don't want to 
put pressure on kmem_map (don't want those dreaded "out of space in 
kmem_map" panics).

         -- Jason R. Thorpe <thorpej@wasabisystems.com>