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