MEMORYALLOCATORS(9) | Kernel Developer's Manual | MEMORYALLOCATORS(9) |
memoryallocators
—
You should use the kmem(9) allocator for all allocations unless you have special needs that it does not provide, such as:
kmem(9) is fast and requires no setup. It cannot be used from interrupt context.
Internally, kmem(9) is implemented using a collection of pool caches for common small allocation sizes, so there is no performance benefit to using a pool cache if you have no other needs.
A pool can be configured with a low-water mark to reserve a minimum number of objects available, a high-water mark to bound the maximum number of objects in reserve, and a hard limit to bound on the maximum number of objects in use.
pool_get(9) can be used to allocate memory in interrupt context for objects that have been reserved in advance, with the possibility of failure if there are none.
By default, pool(9) allocates pageable RAM-backed kernel virtual address space from the same backing store as kmem(9), but it can be configured to allocate any kind of resource with a custom allocator.
The per-CPU cache makes allocation much cheaper — no interprocessor synchronization in the fast case — at the cost of potentially caching some extra resources on one CPU that cannot be used by another.
In addition to all the features of a pool like a custom backing allocator, a pool cache also supports a constructor and destructor routine for when objects are drawn from the shared pool in case the per-CPU cache is empty, or returned to it when the cache is full. This can reduce the cost of reusable initialization and finalization, or associate objects with CPU-local resources.
PAGE_SIZE
, with wired RAM backing, pageable RAM
backing, or backing to be supplied by the caller with
pmap(9).
October 28, 2017 | NetBSD 9.0 |