Subject: Re: pool(9) revisited
To: None <tech-kern@NetBSD.ORG>
From: Paul Kranenburg <pk@cs.few.eur.nl>
List: tech-kern
Date: 07/19/1998 01:30:02
Draft manual page for the revised pool(9) manager.
------
POOL(9) NetBSD Kernel Manual POOL(9)
NAME
pool_create, pool_destroy, pool_get, pool_put, pool_prime - resource-pool
manager
SYNOPSIS
#include <sys/malloc.h>
#include <sys/pool.h>
struct pool *
pool_create(size_t size, u_int align, u_int align_offset, int nitems,
char *wchan, u_int pagesz,
void *(*palloc)(unsigned long sz, int flags, int tag),
void (*prelease)(void *, unsigned long sz, int tag), int tag);
void *
pool_get(struct pool *pp, int flags);
void
pool_put(struct pool *pp, void *item);
int
pool_prime(struct pool *pp, int nitems, caddr_t storage);
pool_sethiwat(struct pool *pp, int n);
pool_setlowat(struct pool *pp, int n);
POOL_STORAGE_SIZE(size, nitems);
DESCRIPTION
These utility routines provide management of pools of fixed-sized areas
of memory. Resource pools set aside an amount of memory for exclusive use
by the resource pool owner. This can be used by applications to guarantee
the availability of a minimum amount of memory needed to continue opera-
tion independent of the memory resources currently available from the
system-wide memory allocator (malloc(9)). The pool manager can optionally
obtain temporary memory by calling the palloc() function passed to
pool_create(), for extra pool items in case the number of allocations ex-
ceeds the nominal number of pool items managed by a pool resource. This
temporary memory will be automatically returned to the system at a later
time.
The function pool_create() initializes a resource pool and returns a han-
dle to it. The arguments are:
size specifies the size of the memory items managed by the
pool.
align Specifies the memory address aligment of the items re-
turned by pool_get(). This argument must be a power of
two. If zero, the alignment defaults to a architecture-
specific natural aligment.
align_offset
The offset within an item to which the align parameter
applies.
nitems specifies the number of memory items that are allocated
to the pool at creation time. This number may be zero, in
which case pool_prime() can be used at a later time to
add permanent items to the pool.
wchan the `wait channel' passed on to tsleep(9) if pool_get()
must wait for items to be returned to the pool.
pagesz The unit which is used to allocate additional memory to
the pool. It must be a power of two.
palloc is called to add additional memory if the pool is deplet-
ed. It returns pagesz aligned memory. The argument sz
will be a multiple of pagesz.
prelease is called to release pages back to the system. palloc()
and prelease() may be NULL, in which case the pool manag-
er uses uvm_km_kmemalloc(9) and uvm_km_free(9) to allo-
cate and release memory using the kernel_map (seeUVM(9)).
mtag the memory tag passed to palloc() and prelease() when allo-
cating or releasing memory pages.
If not enough memory is available to create the pool resource,
pool_create() returns NULL. If the storage parameter is used, the client
is responsible for providing enough storage to accommodate the number of
pool items specified by nitems, as well as the space required by the
pool's administrative overhead (i.e. the pool handle).
pool_get() allocates an item from the pool and returns a pointer to it.
pp The handle identifying the pool resource instance.
flags One of PR_URGENT or PR_WAITOK, that define behaviour in case
the pooled resources are depleted. If no resources are
available and PR_WAITOK is given, this function will wait
until items are returned to the pool, otherwise pool_get()
returns NULL. If PR_URGENT is specified and no items are
available and palloc() cannot allocate a new page, the sys-
tem will panic (XXX).
pool_put() returns the pool item pointed at by item to the resource pool
identified by the pool handle pp. If the number of available items in the
pool exceeds the maximum pool size set by pool_sethiwat() and there are
no out-standing requests for pool items, the excess items will be re-
turned to the system by calling prelease().
pp The handle identifying the pool resource instance.
item A pointer to a pool item previously obtained by pool_get().
pool_prime() adds items to the pool.
pp The handle identifying the pool resource instance.
nitems The number of items to add to the pool. Storage for the
pool items can be passed in the storage argument. If this
parameter is NULL, the items are allocated by using
malloc(9). This function may return ENOMEM in case the re-
quested number of items could not be allocated. Otherwise,
the return value is 0.
pool_sethiwat()
pp The handle identifying the pool resource instance.
n The maximum number of items to keep in the pool. As items
are returned and the total number of pages in the pool is
larger than the maximum set by this function, any completely
unused pages are released immediately (by calling
prelease()). If this function is not used to specify a max-
imum number of items, the pages will remain associated with
the pool until the system runs low on memory at which point
the VM system will try to reclaim unused pages.
pool_setlowat()
pp The handle identifying the pool resource instance.
n The minimum number of items to keep in the pool. The number
pages in the pool will not decrease below the required value
to accommodate the minimum number of items specified by this
function. Unlike pool_prime(), this function does not allo-
cate the necessary memory upfront.
Note that undefined behaviour results when mixing the storage providing
methods supported by the pool resource routines.
The pool resource code uses a per-pool lock to protect the internal
state. If a pool is used from an interrupt context, the caller is re-
sponsible for blocking interrupts appropriately.
Pool usage logs can be enabled by defining the compile-time option
POOL_DIAGNOSTIC.
RETURN VALUES
EXAMPLES
CODE REFERENCES
The pool manager is implemented in the file sys/kern/subr_pool.c.
AUTHOR
SEE ALSO
malloc(9), free(9). uvm(9).
HISTORY
The NetBSD pool manager appeared in NetBSD 1.4.
NetBSD December 4, 1997 3