Fix spellings of slab allocator section in init/Kconfig

Fix some of the spelling issues. Fix sentences. Discourage SLOB use
since SLUB can pack objects denser.

Signed-off-by: Christoph Lameter <clameter@sgi.com>
Cc: Matt Mackall <mpm@selenic.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
Christoph Lameter 2007-05-09 02:32:47 -07:00 committed by Linus Torvalds
parent 7ae439ce0c
commit 34013886ef

View File

@ -523,9 +523,9 @@ config SLAB
bool "SLAB" bool "SLAB"
help help
The regular slab allocator that is established and known to work The regular slab allocator that is established and known to work
well in all environments. It organizes chache hot objects in well in all environments. It organizes cache hot objects in
per cpu and per node queues. SLAB is the default choice for per cpu and per node queues. SLAB is the default choice for
slab allocator. a slab allocator.
config SLUB config SLUB
depends on EXPERIMENTAL && !ARCH_USES_SLAB_PAGE_STRUCT depends on EXPERIMENTAL && !ARCH_USES_SLAB_PAGE_STRUCT
@ -535,21 +535,20 @@ config SLUB
instead of managing queues of cached objects (SLAB approach). instead of managing queues of cached objects (SLAB approach).
Per cpu caching is realized using slabs of objects instead Per cpu caching is realized using slabs of objects instead
of queues of objects. SLUB can use memory efficiently of queues of objects. SLUB can use memory efficiently
way and has enhanced diagnostics. and has enhanced diagnostics.
config SLOB config SLOB
# #
# SLOB cannot support SMP because SLAB_DESTROY_BY_RCU does not work # SLOB does not support SMP because SLAB_DESTROY_BY_RCU is unsupported
# properly.
# #
depends on EMBEDDED && !SMP && !SPARSEMEM depends on EMBEDDED && !SMP && !SPARSEMEM
bool "SLOB (Simple Allocator)" bool "SLOB (Simple Allocator)"
help help
SLOB replaces the SLAB allocator with a drastically simpler SLOB replaces the SLAB allocator with a drastically simpler
allocator. SLOB is more space efficient that SLAB but does not allocator. SLOB is more space efficient that SLAB but does not
scale well (single lock for all operations) and is more susceptible scale well (single lock for all operations) and is also highly
to fragmentation. SLOB it is a great choice to reduce susceptible to fragmentation. SLUB can accomplish a higher object
memory usage and code size for embedded systems. density. It is usually better to use SLUB instead of SLOB.
endchoice endchoice