Subject: Re: pool(9) revisited
To: Paul Kranenburg <pk@cs.few.eur.nl>
From: Jason Thorpe <thorpej@nas.nasa.gov>
List: tech-kern
Date: 07/13/1998 08:05:16
On Mon, 13 Jul 98 12:45:27 +0200 
 Paul Kranenburg <pk@cs.few.eur.nl> wrote:

 > 	* cache coloring: skew the offset of items in a page to obtain
 > 	  a more homogeneous distribution of KVAs wrt. hardware caches

Ah, cool :-)

 > 	* no fixed upper limit on a pool's size. Let the page daemon
 > 	  reclaim pages when running low on memory.
 > 	  Optionally set a minimum amount of pool items that cannot be
 > 	  reclaimed.

...that works if you use pageable memory... but for some things, I might
want to allocate a page, and map it w/ e.g. a direct-mapped segment (like
KSEG/KSEG0 on Alpha or MIPS).  So, this has to be limited for use by
the default allocator your pool code provides.

 > 	* time limit on recently used pages; the reclaim function will
 > 	  not release a page from a pool until N seconds have elapsed
 > 	  since that page was last used (to avoid thrashing)

That is definitely a good idea.

 > On my test machine, I've used pools to replace these private queues:
 > 
 > 	* pmap/sun4m: pagetables
 > 	* uvm_swap: all pre-allocated swap buffers +
 > 		    auxiliary buffers for swapping to files.

...in uvm, I want this for amap-related data structures.  The current scheme
of malloc/free eats up kmem_map.  On systems where it's possible, I'd like
to use direct-mapped segments for these things.

 > 	* regular mbufs (instead of MALLOC/FREE)

Oh, I bet that makes mbuf allocation a bit faster, actually...

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-5                                       Work: +1 650 604 0935
Moffett Field, CA 94035                             Pager: +1 650 940 5942