출처 : http://www.usenix.org/publications/library/proceedings/bos94/full_papers/bonwick.a
The Slab Allocator:
An Object-Caching Kernel Memory Allocator
Jeff Bonwick
Sun Microsystems
Abstract
This paper presents a comprehensive design overview of the SunOS 5.4 kernel
memory allocator. This allocator is based on a set of object-caching primi-
tives that reduce the cost of allocating complex objects by retaining their
state between uses. These same primitives prove equally effective for manag-
ing stateless memory (e.g. data pages and temporary buffers) because they are
space-efficient and fast. The allocator's object caches respond dynamically
to global memory pressure, and employ an object-coloring scheme that improves
the system's overall cache utilization and bus balance. The allocator also
has several statistical and debugging features that can detect a wide range of
problems throughout the system.
1. Introduction
The allocation and freeing of objects are among the most common operations in
the kernel. A fast kernel memory allocator is therefore essential. However,
in many cases the cost of initializing and destroying the object exceeds the
cost of allocating and freeing memory for it. Thus, while improvements in the
allocator are beneficial, even greater gains can be achieved by caching fre-
quently used objects so that their basic structure is preserved between uses.
The paper begins with a discussion of object caching, since the interface
that this requires will shape the rest of the allocator. The next section
then describes the implementation in detail. Section 4 describes the effect
of buffer address distribution on the system's overall cache utilization and
bus balance, and shows how a simple coloring scheme can improve both. Section
5 compares the allocator's performance to several other well-known kernel
memory allocators and finds that it is generally superior in both space and
time. Finally, Section 6 describes the allocator's debugging features, which
can detect a wide variety of problems throughout the system.
2. Object Caching
Object caching is a technique for dealing with objects that are frequently
allocated and freed. The idea is to preserve the invariant portion of an
object's initial state - its constructed state - between uses, so it does not
have to be destroyed and recreated every time the object is used. For exam-
ple, an object containing a mutex only needs to have mutex_init() applied
once - the first time the object is allocated. The object can then be freed
and reallocated many times without incurring the expense of mutex_destroy()
and mutex_init() each time. An object's embedded locks, condition variables,
reference counts, lists of other objects, and read-only data all generally
qualify as constructed state.
Caching is important because the cost of constructing an object can be
significantly higher than the cost of allocating memory for it. For example,
on a SPARCstation-2 running a SunOS 5.4 development kernel, the allocator
presented here reduced the cost of allocating and freeing a stream head from
33 microseconds to 5.7 microseconds. As the table below illustrates, most of
the savings was due to object caching:
______________________________________________________________________________
Stream Head Allocation + Free Costs (usec)
______________________________________________________________________________
construction memory other
allocator + destruction allocation init.
______________________________________________________________________________
old 23.6 9.4 1.9
new 0.0 3.8 1.9
______________________________________________________________________________
Caching is particularly beneficial in a multithreaded environment, where
many of the most frequently allocated objects contain one or more embedded
locks, condition variables, and other constructible state.
The design of an object cache is straightforward:
To allocate an object:
if (there's an object in the cache)
take it (no construction required);
else {
allocate memory;
construct the object;
}
To free an object:
return it to the cache (no destruction required);
To reclaim memory from the cache:
take some objects from the cache;
destroy the objects;
free the underlying memory;
An object's constructed state must be initialized only once - when the
object is first brought into the cache. Once the cache is populated, allocat-
ing and freeing objects are fast, trivial operations.
2.1. An Example
Consider the following data structure:
struct foo {
kmutex_t foo_lock;
kcondvar_t foo_cv;
struct bar *foo_barlist;
int foo_refcnt;
};
Assume that a foo structure cannot be freed until there are no outstanding
references to it (foo_refcnt == 0) and all of its pending bar events (whatever
they are) have completed (foo_barlist == NULL). The life cycle of a dynami-
cally allocated foo would be something like this:
foo = kmem_alloc(sizeof (struct foo),
KM_SLEEP);
mutex_init(&foo->foo_lock, ...);
cv_init(&foo->foo_cv, ...);
foo->foo_refcnt = 0;
foo->foo_barlist = NULL;
use foo;
ASSERT(foo->foo_barlist == NULL);
ASSERT(foo->foo_refcnt == 0);
cv_destroy(&foo->foo_cv);
mutex_destroy(&foo->foo_lock);
kmem_free(foo);
Notice that between each use of a foo object we perform a sequence of opera-
tions that constitutes nothing more than a very expensive no-op. All of this
overhead (i.e., everything other than ``use foo'' above) can be eliminated by
object caching.
2.2. The Case for Object Caching in the Central Allocator
Of course, object caching can be implemented without any help from the central
allocator - any subsystem can have a private implementation of the algorithm
described above. However, there are several disadvantages to this approach:
(1) There is a natural tension between an object cache, which wants to keep
memory, and the rest of the system, which wants that memory back.
Privately-managed caches cannot handle this tension sensibly. They have
limited insight into the system's overall memory needs and no insight into
each other's needs. Similarly, the rest of the system has no knowledge of
the existence of these caches and hence has no way to ``pull'' memory from
them.
(2) Since private caches bypass the central allocator, they also bypass any
accounting mechanisms and debugging features that allocator may possess.
This makes the operating system more difficult to monitor and debug.
(3) Having many instances of the same solution to a common problem increases
kernel code size and maintenance costs.
Object caching requires a greater degree of cooperation between the allocator
and its clients than the standard kmem_alloc(9F)/kmem_free(9F) interface
allows. The next section develops an interface to support constructed object
caching in the central allocator.
2.3. Object Cache Interface
The interface presented here follows from two observations:
(A) Descriptions of objects (name, size, alignment, constructor, and destruc-
tor) belong in the clients - not in the central allocator. The allocator
should not just ``know'' that sizeof (struct inode) is a useful pool size,
for example. Such assumptions are brittle [Grunwald93A] and cannot
anticipate the needs of third-party device drivers, streams modules and
file systems.
(B) Memory management policies belong in the central allocator - not in its
clients. The clients just want to allocate and free objects quickly. They
shouldn't have to worry about how to manage the underlying memory effi-
ciently.
It follows from (A) that object cache creation must be client-driven and must
include a full specification of the objects:
(1) struct kmem_cache *kmem_cache_create(char *name, size_t size, int align,
void (*constructor)(void *, size_t),
void (*destructor)(void *, size_t));
Creates a cache of objects, each of size size, aligned on an align boundary.
The alignment will always be rounded up to the minimum allowable value, so
align can be zero whenever no special alignment is required. name identi-
fies the cache for statistics and debugging. constructor is a function that
constructs (that is, performs the one-time initialization of) objects in the
cache; destructor undoes this, if applicable. The constructor and destruc-
tor take a size argument so that they can support families of similar
caches, e.g. streams messages. kmem_cache_create returns an opaque descrip-
tor for accessing the cache.
Next, it follows from (B) that clients should need just two simple functions
to allocate and free objects:
(2) void *kmem_cache_alloc(struct kmem_cache *cp, int flags);
Gets an object from the cache. The object will be in its constructed state.
flags is either KM_SLEEP or KM_NOSLEEP, indicating whether it's acceptable
to wait for memory if none is currently available.
(3) void kmem_cache_free(struct kmem_cache *cp, void *buf);
Returns an object to the cache. The object must still be in its constructed
state.
Finally, if a cache is no longer needed the client can destroy it:
(4) void kmem_cache_destroy(struct kmem_cache *cp);
Destroys the cache and reclaims all associated resources. All allocated
objects must have been returned to the cache.
This interface allows us to build a flexible allocator that is ideally suited
to the needs of its clients. In this sense it is a ``custom'' allocator.
However, it does not have to be built with compile-time knowledge of its
clients as most custom allocators do [Bozman84A, Grunwald93A, Margolin71], nor
does it have to keep guessing as in the adaptive-fit methods [Bozman84B,
Leverett82, Oldehoeft85]. Rather, the object-cache interface allows clients
to specify the allocation services they need on the fly.
2.4. An Example
This example demonstrates the use of object caching for the ``foo'' objects
introduced in Section 2.1. The constructor and destructor routines are:
void
foo_constructor(void *buf, int size)
{
struct foo *foo = buf;
mutex_init(&foo->foo_lock, ...);
cv_init(&foo->foo_cv, ...);
foo->foo_refcnt = 0;
foo->foo_barlist = NULL;
}
void
foo_destructor(void *buf, int size)
{
struct foo *foo = buf;
ASSERT(foo->foo_barlist == NULL);
ASSERT(foo->foo_refcnt == 0);
cv_destroy(&foo->foo_cv);
mutex_destroy(&foo->foo_lock);
}
To create the foo cache:
foo_cache = kmem_cache_create("foo_cache", sizeof (struct foo), 0,
foo_constructor, foo_destructor);
To allocate, use, and free a foo object:
foo = kmem_cache_alloc(foo_cache, KM_SLEEP);
use foo;
kmem_cache_free(foo_cache, foo);
This makes foo allocation fast, because the allocator will usually do
nothing more than fetch an already-constructed foo from the cache.
foo_constructor and foo_destructor will be invoked only to populate and drain
the cache, respectively.
The example above illustrates a beneficial side-effect of object caching:
it reduces the instruction-cache footprint of the code that uses cached
objects by moving the rarely-executed construction and destruction code out of
the hot path.
3. Slab Allocator Implementation
This section describes the implementation of the SunOS 5.4 kernel memory allo-
cator, or ``slab allocator,'' in detail. (The name derives from one of the
allocator's main data structures, the slab. The name stuck within Sun because
it was more distinctive than ``object'' or ``cache.'' Slabs will be discussed
in Section 3.2.)
The terms object, buffer, and chunk will be used more or less inter-
changeably, depending on how we're viewing that piece of memory at the moment.
3.1. Caches
Each cache has a front end and back end which are designed to be as decoupled
as possible:
back end front end
-------- ---------
---------------
kmem_cache_grow() --> | | --> kmem_cache_alloc()
| cache |
kmem_cache_reap() <-- | | <-- kmem_cache_free()
---------------
The front end is the public interface to the allocator. It moves objects to
and from the cache, calling into the back end when it needs more objects.
The back end manages the flow of real memory through the cache. The
influx routine (kmem_cache_grow()) gets memory from the VM system, makes
objects out of it, and feeds those objects into the cache. The outflux rou-
tine (kmem_cache_reap()) is invoked by the VM system when it wants some of
that memory back - e.g., at the onset of paging. Note that all back-end
activity is triggered solely by memory pressure. Memory flows in when the
cache needs more objects and flows back out when the rest of the system needs
more pages; there are no arbitrary limits or watermarks. Hysteresis control
is provided by a working-set algorithm, described in Section 3.4.
The slab allocator is not a monolithic entity, but rather is a loose con-
federation of independent caches. The caches have no shared state, so the
allocator can employ per-cache locking instead of protecting the entire arena
(kernel heap) with one global lock. Per-cache locking improves scalability
by allowing any number of distinct caches to be accessed simultaneously.
Each cache maintains its own statistics - total allocations, number of
allocated and free buffers, etc. These per-cache statistics provide insight
into overall system behavior. They indicate which parts of the system consume
the most memory and help to identify memory leaks. They also indicate the
activity level in various subsystems, to the extent that allocator traffic is
an accurate approximation. (Streams message allocation is a direct measure of
streams activity, for example.)
The slab allocator is operationally similar to the ``CustoMalloc''
[Grunwald93A], ``QuickFit'' [Weinstock88], and ``Zone'' [VanSciver88] alloca-
tors, all of which maintain distinct freelists of the most commonly requested
buffer sizes. The Grunwald and Weinstock papers each demonstrate that a cus-
tomized segregated-storage allocator - one that has a priori knowledge of the
most common allocation sizes - is usually optimal in both space and time. The
slab allocator is in this category, but has the advantage that its customiza-
tions are client-driven at run time rather than being hard-coded at compile
time. (This is also true of the Zone allocator.)
The standard non-caching allocation routines, kmem_alloc(9F) and
kmem_free(9F), use object caches internally. At startup, the system
creates a set of about 30 caches ranging in size from 8 bytes to 9K in roughly
10-20% increments. kmem_alloc() simply performs a kmem_cache_alloc() from the
nearest-size cache. Allocations larger than 9K, which are rare, are handled
directly by the back-end page supplier.
3.2. Slabs
The slab is the primary unit of currency in the slab allocator. When the
allocator needs to grow a cache, for example, it acquires an entire slab of
objects at once. Similarly, the allocator reclaims unused memory (shrinks a
cache) by relinquishing a complete slab.
A slab consists of one or more pages of virtually contiguous memory
carved up into equal-size chunks, with a reference count indicating how many
of those chunks have been allocated. The benefits of using this simple data
structure to manage the arena are somewhat striking:
(1) Reclaiming unused memory is trivial. When the slab reference count goes
to zero the associated pages can be returned to the VM system. Thus a simple
reference count replaces the complex trees, bitmaps, and coalescing algorithms
found in most other allocators [Knuth68, Korn85, Standish80].
(2) Allocating and freeing memory are fast, constant-time operations. All we
have to do is move an object to or from a freelist and update a reference
count.
(3) Severe external fragmentation (unused buffers on the freelist) is
unlikely. Over time, many allocators develop an accumulation of small, unus-
able buffers. This occurs as the allocator splits existing free buffers to
satisfy smaller requests. For example, the right sequence of 32-byte and 40-
byte allocations may result in a large accumulation of free 8-byte buffers -
even though no 8-byte buffers are ever requested [Standish80]. A segregated-
storage allocator cannot suffer this fate, since the only way to populate its
8-byte freelist is to actually allocate and free 8-byte buffers. Any sequence
of 32-byte and 40-byte allocations - no matter how complex - can only result
in population of the 32-byte and 40-byte freelists. Since prior allocation is
a good predictor of future allocation [Weinstock88] these buffers are likely
to be used again.
The other reason that slabs reduce external fragmentation is that all objects
in a slab are of the same type, so they have the same lifetime distribution.
(The generic caches that back kmem_alloc() are a notable exception, but they
constitute a relatively small fraction of the arena in SunOS 5.4 - all of the
major consumers of memory now use kmem_cache_alloc().) The resulting
segregation of short-lived and long-lived objects at slab granularity
reduces the likelihood of an entire page being held hostage due to a
single long-lived allocation [Barrett93, Hanson90].
(4) Internal fragmentation (per-buffer wasted space) is minimal. Each buffer
is exactly the right size (namely, the cache's object size), so the only
wasted space is the unused portion at the end of the slab. For example,
assuming 4096-byte pages, the slabs in a 400-byte object cache would each con-
tain 10 buffers, with 96 bytes left over. We can view this as equivalent 9.6
bytes of wasted space per 400-byte buffer, or 2.4% internal fragmentation.
In general, if a slab contains n buffers, then the internal fragmentation is
at most 1/n; thus the allocator can actually control the amount of internal
fragmentation by controlling the slab size. However, larger slabs are more
likely to cause external fragmentation, since the probability of being able to
reclaim a slab decreases as the number of buffers per slab increases. The
SunOS 5.4 implementation limits internal fragmentation to 12.5% (1/8), since
this was found to be the empirical sweet-spot in the trade-off between inter-
nal and external fragmentation.
3.2.1. Slab Layout - Logical
The contents of each slab are managed by a kmem_slab data structure that main-
tains the slab's linkage in the cache, its reference count, and its list of
free buffers. In turn, each buffer in the slab is managed by a kmem_bufctl
structure that holds the freelist linkage, buffer address, and a back-pointer
to the controlling slab. Pictorially, a slab looks like this (bufctl-to-slab
back-pointers not shown):
--------
| kmem |
| slab |
--------
|
|
V
-------- -------- --------
| kmem | -----> | kmem | -----> | kmem |
|bufctl| |bufctl| |bufctl|
-------- -------- --------
| | |
| | |
V V V
--------------------------------------------------------
| | | | |
| buf | buf | buf |unused|
| | | | |
--------------------------------------------------------
|<---------------- one or more pages ----------------->|
3.2.2. Slab Layout for Small Objects
For objects smaller than 1/8 of a page, a slab is built by allocating a page,
placing the slab data at the end, and dividing the rest into equal-size
buffers:
------------------------ --------------------------------------
| | | | | | un- | kmem |
| buf | buf | ... | buf | buf | used | slab |
| | | | | | | data |
------------------------ --------------------------------------
|<------------------------- one page -------------------------->|
Each buffer serves as its own bufctl while on the freelist. Only the linkage
is actually needed, since everything else is computable. These are essential
optimizations for small buffers - otherwise we would end up allocating almost
as much memory for bufctls as for the buffers themselves.
The freelist linkage resides at the end of the buffer, rather than the
beginning, to facilitate debugging. This is driven by the empirical observa-
tion that the beginning of a data structure is typically more active than the
end. If a buffer is modified after being freed, the problem is easier to
diagnose if the heap structure (freelist linkage) is still intact.
The allocator reserves an additional word for constructed objects so that
the linkage doesn't overwrite any constructed state.
3.2.3. Slab Layout for Large Objects
The above scheme is efficient for small objects, but not for large ones. It
could fit only one 2K buffer on a 4K page because of the embedded slab data.
Moreover, with large (multi-page) slabs we lose the ability to determine the
slab data address from the buffer address. Therefore, for large objects the
physical layout is identical to the logical layout. The required slab and
bufctl data structures come from their own (small-object!) caches. A per-
cache self-scaling hash table provides buffer-to-bufctl conversion.
3.3. Freelist Management
Each cache maintains a circular, doubly-linked list of all its slabs. The
slab list is partially sorted, in that the empty slabs (all buffers allocated)
come first, followed by the partial slabs (some buffers allocated, some free),
and finally the complete slabs (all buffers free, refcnt == 0). The cache's
freelist pointer points to its first non-empty slab. Each slab, in turn, has
its own freelist of available buffers. This two-level freelist structure sim-
plifies memory reclaiming. When the allocator reclaims a slab it doesn't have
to unlink each buffer from the cache's freelist - it just unlinks the slab.
3.4. Reclaiming Memory
When kmem_cache_free() sees that the slab reference count is zero, it does not
immediately reclaim the memory. Instead, it just moves the slab to the tail
of the freelist where all the complete slabs reside. This ensures that no
complete slab will be broken up unless all partial slabs have been depleted.
When the system runs low on memory it asks the allocator to liberate as
much memory as it can. The allocator obliges, but retains a 15-second working
set of recently-used slabs to prevent thrashing. Measurements indicate that
system performance is fairly insensitive to the slab working-set interval.
Presumably this is because the two extremes - zero working set (reclaim all
complete slabs on demand) and infinite working-set (never reclaim anything) -
are both reasonable, albeit suboptimal, policies.
4. Hardware Cache Effects
Modern hardware relies on good cache utilization, so it is important to design
software with cache effects in mind. For a memory allocator there are two
broad classes of cache effects to consider: the distribution of buffer
addresses and the cache footprint of the allocator itself. The latter topic
has received some attention [Chen93, Grunwald93B], but the effect of buffer
address distribution on cache utilization and bus balance has gone largely
unrecognized.
4.1. Impact of Buffer Address Distribution on Cache Utilization
The address distribution of mid-size buffers can affect the system's overall
cache utilization. In particular, power-of-two allocators - where all buffers
are 2n bytes and are 2n-byte aligned - are pessimal. (Such allocators are
common because they are easy to implement. For example, 4.4BSD and SVr4 both
employ power-of-two methods [McKusick88, Lee89].) Suppose, for example,
that every inode (~=300 bytes) is assigned a 512-byte buffer, 512-byte aligned,
and that only the first dozen fields of an inode (48 bytes) are frequently
referenced. Then the majority of inode-related memory traffic will be at
addresses between 0 and 47 modulo 512. Thus the cache lines near 512-byte
boundaries will be heavily loaded while the rest lie fallow. In effect only
9% (48/512) of the cache will be usable by inodes. Fully-associative caches
would not suffer this problem, but current hardware trends are toward simpler
rather than more complex caches.
Of course, there's nothing special about inodes. The kernel contains
many other mid-size data structures (e.g. 100-500 bytes) with the same essen-
tial qualities: there are many of them, they contain only a few heavily used
fields, and those fields are grouped together at or near the beginning of the
structure. This artifact of the way data structures evolve has not previously
been recognized as an important factor in allocator design.
4.2. Impact of Buffer Address Distribution on Bus Balance
On a machine that interleaves memory across multiple main buses, the effects
described above also have a significant impact on bus utilization. The
SPARCcenter 2000, for example, employs 256-byte interleaving across two main
buses [Cekleov92]. Continuing the example above, we see that any power-of-two
allocator maps the first half of every inode (the hot part) to bus 0 and the
second half to bus 1. Thus almost all inode-related cache misses are serviced
by bus 0. The situation is exacerbated by an inflated miss rate, since all
of the inodes are fighting over a small fraction of the cache.
These effects can be dramatic. On a SPARCcenter 2000 running LADDIS
under a SunOS 5.4 development kernel, replacing the old allocator (a power-
of-two buddy-system [Lee89]) with the slab allocator reduced bus imbalance
from 43% to just 17%. In addition, the primary cache miss rate dropped by
13%.
4.3. Slab Coloring
The slab allocator incorporates a simple coloring scheme that distributes
buffers evenly throughout the cache, resulting in excellent cache utilization
and bus balance. The concept is simple: each time a new slab is created, the
buffer addresses start at a slightly different offset (color) from the slab
base (which is always page-aligned). For example, for a cache of 200-byte
objects with 8-byte alignment, the first slab's buffers would be at addresses
0, 200, 400, ... relative to the slab base. The next slab's buffers would be
at offsets 8, 208, 408, ... and so on. The maximum slab color is determined
by the amount of unused space in the slab. In this example, assuming 4K
pages, we can fit 20 200-byte buffers in a 4096-byte slab. The buffers con-
sume 4000 bytes, the kmem_slab data consumes 32 bytes, and the remaining 64
bytes are available for coloring. Thus the maximum slab color is 64, and the
slab color sequence is 0, 8, 16, 24, 32, 40, 48, 56, 64, 0, 8, ...
One particularly nice property of this coloring scheme is that mid-size
power-of-two buffers receive the maximum amount of coloring, since they are
the worst-fitting. For example, while 128 bytes goes perfectly into 4096, it
goes near-pessimally into 4096 - 32, which is what's actually available
(because of the embedded slab data).
4.4. Arena Management
An allocator's arena management strategy determines its dynamic cache foot-
print. These strategies fall into three broad categories: sequential-fit
methods, buddy methods, and segregated-storage methods [Standish80].
A sequential-fit allocator must typically search several nodes to find a
good-fitting buffer. Such methods are, by nature, condemned to a large cache
footprint: they have to examine a significant number of nodes that are gen-
erally nowhere near each other. This causes not only cache misses, but TLB
misses as well. The coalescing stages of buddy-system allocators [Knuth68,
Lee89] have similar properties.
A segregated-storage allocator, such as the slab allocator, maintains
separate freelists for different buffer sizes. These allocators generally have
good cache locality because allocating a buffer is so simple. All the alloca-
tor has to do is determine the freelist (by computation, by table lookup, or
by having it supplied as an argument) and take a buffer from it. Freeing a
buffer is similarly straightforward. There are only a handful of pointers
to load, so the cache footprint is small.
The slab allocator has the additional advantage that for small to mid-
size buffers, most of the relevant information - the slab data, bufctls, and
buffers themselves - resides on a single page. Thus a single TLB entry covers
most of the action.
5. Performance
This section compares the performance of the slab allocator to three other
well-known kernel memory allocators:
SunOS 4.1.3, based on [Stephenson83], a sequential-fit method;
4.4BSD, based on [McKusick88], a power-of-two segregated-storage method;
SVr4, based on [Lee89], a power-of-two buddy-system method. This allocator
was employed in all previous SunOS 5.x releases.
To get a fair comparison, each of these allocators was ported into the same
SunOS 5.4 base system. This ensures that we are comparing just allocators,
not entire operating systems.
5.1. Speed Comparison
On a SPARCstation-2 the time required to allocate and free a buffer under the
various allocators is as follows:
______________________________________________________________________________
Memory Allocation + Free Costs
______________________________________________________________________________
allocator time (usec) interface
______________________________________________________________________________
slab 3.8 kmem_cache_alloc
4.4BSD 4.1 kmem_alloc
slab 4.7 kmem_alloc
SVr4 9.4 kmem_alloc
SunOS 4.1.3 25.0 kmem_alloc
______________________________________________________________________________
Note: The 4.4BSD allocator offers both functional and preprocessor macro
interfaces. These measurements are for the functional version. Non-binary
interfaces in general were not considered, since these cannot be exported to
drivers without exposing the implementation. The 4.4BSD allocator was com-
piled without KMEMSTATS defined (it's on by default) to get the fastest possi-
ble code.
A mutex_enter()/mutex_exit() pair costs 1.0 usec, so the locking required
to allocate and free a buffer imposes a lower bound of 2.0 usec. The slab and
4.4BSD allocators are both very close to this limit because they do very lit-
tle work in the common cases. The 4.4BSD implementation of kmem_alloc() is
slightly faster, since it has less accounting to do (it never reclaims
memory). The slab allocator's kmem_cache_alloc() interface is even faster,
however, because it doesn't have to determine which freelist (cache) to use -
the cache descriptor is passed as an argument to kmem_cache_alloc(). In any
event, the differences in speed between the slab and 4.4BSD allocators are
small. This is to be expected, since all segregated-storage methods are
operationally similar. Any good segregated-storage implementation should
achieve excellent performance.
The SVr4 allocator is slower than most buddy systems but still provides
reasonable, predictable speed. The SunOS 4.1.3 allocator, like most
sequential-fit methods, is comparatively slow and quite variable.
Th
'[OS] > Embedded&Linux' 카테고리의 다른 글
| svn restore (0) | 2007.10.17 |
|---|---|
| trac backup & restore (0) | 2007.10.17 |
| libumem 라이브러리를 이용하여 어플리케이션 내의 메모리 관리 버그를 잡아 내는 방법 (0) | 2007.10.15 |
| 리눅스에 스토리지 붙이기 - Fedora 7 - (0) | 2007.10.13 |
| VMwere 에 페도라 7 설치하기 -VMwere 설정 편- (0) | 2007.10.12 |