svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
uma_zfree(9)
The zone allocator provides an efficient interface for managing
dynamically-sized collections of items of identical size. The
zone allocator can work with preallocated zones as well as with
runtime-allocated ones, and is therefore available much earlier
in the boot process than other memory management routines. The
zone allocator provides per-cpu allocation caches with linear
scalability on SMP systems as well as round-robin and first-touch
policies for NUMA systems. A zone is an extensible collection of
items of identical size. The zone allocator keeps track of which
items are in use and which are not, and provides functions for
allocating items from the zone and for releasing them back (which
makes them available for later use). After the first allocation
of an item, it will have been cleared to zeroes, however subse‐
quent allocations will retain the contents as of the last free.
The function creates a new zone from which items may then be al‐
located from. The argument is a text name of the zone for debug‐
ging and stats; this memory should not be freed until the zone
has been deallocated. The and arguments are callback functions
that are called by the uma subsystem at the time of the call to
and respectively. Their purpose is to provide hooks for initial‐
izing or destroying things that need to be done at the time of
the allocation or release of a resource. A good usage for the
and callbacks might be to adjust a global count of the number of
objects allocated. The and arguments are used to optimize the
allocation of objects from the zone. They are called by the uma
subsystem whenever it needs to allocate or free several items to
satisfy requests or memory pressure. A good use for the and
callbacks might be to initialize and destroy mutexes contained
within the object. This would allow one to re-use already ini‐
tialized mutexes when an object is returned from the uma subsys‐
tem's object cache. They are not called on each call to and but
rather in a batch mode on several objects. The argument of the
is a subset of the following flags: Slabs of the zone are never
returned back to VM. Pages belonging to the zone will not be in‐
cluded into mini-dumps. An allocation from zone would have
shadow copies, that are privately assigned to CPUs. A CPU can
address its private copy using base allocation address plus mul‐
tiple of current CPU id and foo_zone = uma_zcreate(...,
UMA_ZONE_PCPU);
... foo_base = uma_zalloc(foo_zone, ...);
... critical_enter(); foo_pcpu = (foo_t *)zpcpu_get(foo_base);
/* do something with foo_pcpu */ critical_exit(); By default
book-keeping of items within a slab is done in the slab page it‐
self. This flag explicitly tells subsystem that book-keeping
structure should be allocated separately from special internal
zone. This flag requires either or since subsystem requires a
mechanism to find a book-keeping structure to an item being
freed. The subsystem may choose to prefer offpage book-keeping
for certain zones implicitly. The zone will have its method set
to internal method that initializes a new allocated slab to all
zeros. Do not mistake method with A zone with flag would not re‐
turn zeroed memory on every The zone should use an internal hash
table to find slab book-keeping structure where an allocation be‐
ing freed belongs to. The zone should use special field of to
find slab book-keeping structure where an allocation being freed
belongs to. The zone is for the subsystem. The zone is for the
VM subsystem. The zone should use a first-touch NUMA policy
rather than the round-robin default. Callers that do not free
memory on the same domain it is allocated from will cause mixing
in per-cpu caches. See To allocate an item from a zone, simply
call with a pointer to that zone and set the argument to selected
flags as documented in It will return a pointer to an item if
successful, or in the rare case where all items in the zone are
in use and the allocator is unable to grow the zone and is speci‐
fied. Items are released back to the zone from which they were
allocated by calling with a pointer to the zone and a pointer to
the item. If is then does nothing. The variations and allow
callers to specify an argument for the and functions, respec‐
tively. The function allows callers to specify a fixed the allo‐
cator which reduces concurrency. The function should be used to
return memory allocated in this fashion. This function infers
the domain from the pointer and does not require it as an argu‐
ment. Created zones, which are empty, can be destroyed using
freeing all memory that was allocated for the zone. All items
allocated from the zone with must have been freed with before.
The function limits the number of items that can be allocated to
The argument specifies the requested upper limit number of items.
The effective limit is returned to the caller, as it may end up
being higher than requested due to the implementation rounding up
to ensure all memory pages allocated to the zone are utilised to
capacity. The limit applies to the total number of items in the
zone, which includes allocated items, free items and free items
in the per-cpu caches. On systems with more than one CPU it may
not be possible to allocate the specified number of items even
when there is no shortage of memory, because all of the remaining
free items may be in the caches of the other CPUs when the limit
is hit. The function returns the effective upper limit number of
items for a zone. The function returns the approximate current
occupancy of the zone. The returned value is approximate because
appropriate synchronisation to determine an exact value is not
performed by the implementation. This ensures low overhead at
the expense of potentially stale data being used in the calcula‐
tion. The function sets a warning that will be printed on the
system console when the given zone becomes full and fails to al‐
locate an item. The warning will be printed no more often than
every five minutes. Warnings can be turned off globally by set‐
ting the sysctl tunable to The function sets a function that will
be called when the given zone becomes full and fails to allocate
an item. The function will be called with the zone locked.
Also, the function that called the allocation function may have
held additional locks. Therefore, this function should do very
little work (similar to a signal handler). The macro declares a
static oid that exports the effective upper limit number of items
for a zone. The argument should be a pointer to A read of the
oid returns value obtained through A write to the oid sets new
value via The macro is provided to create this type of oid dynam‐
ically. The macro declares a static read-only oid that exports
the approximate current occupancy of the zone. The argument
should be a pointer to A read of the oid returns value obtained
through The macro is provided to create this type of oid dynami‐
cally. The function returns a pointer to an item, or if the zone
ran out of unused items and was specified. The memory that these
allocation calls return is not executable. The function does not
support the flag to allocate executable memory. Not all plat‐
forms enforce a distinction between executable and non-executable
memory. The zone allocator first appeared in It was radically
changed in to function as a slab allocator. The zone allocator
was written by The zone allocator was rewritten in large parts by
to function as a slab allocator. This manual page was written by
Changes for UMA by