Jan Wieck wrote:
> Right right right! Pooled allocation will gain performance
> and the separate bookkeeping should be more useful.
> But I can think of another thing that might help. A temporary
> allocation pool stack.
> The functions to manage it are:
> void tmppalloc_push(void);
> void tmppalloc_pop(void);
> void *tmppalloc(Size size);
> void *tmpuppalloc(Size size, int levels_up);
You might be interested in:
POOL(9) NetBSD Kernel Manual POOL(9)
pool_create, pool_destroy, pool_get, pool_put, pool_prime - resource-pool
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 con
tinue operation 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 allo
cations exceeds the nominal number of pool items managed by a pool re
source. This temporary memory will be automatically returned to the sys
tem at a later time.
The pool manager is implemented in the file sys/kern/subr_pool.c.
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 1999-01-30 20:18:15|
|Subject: Re: [HACKERS] Postmaster dies with many child processes (spinlock/semget failed) |
|Previous:||From: Cary O'Brien||Date: 1999-01-30 14:08:21|
|Subject: Re: [HACKERS] Postmaster dies with many child processes|