diff options
| author | Christoph Lameter <clameter@sgi.com> | 2007-05-09 02:32:47 -0700 |
|---|---|---|
| committer | Linus Torvalds <torvalds@woody.linux-foundation.org> | 2007-05-09 12:30:46 -0700 |
| commit | 34013886ef47ea72e412beb04558431b57a68d51 (patch) | |
| tree | 2ad144b7da7b689950baca5b9725989b379829c4 /init | |
| parent | 7ae439ce0c01d7db0c70d1542985969e95ef750d (diff) | |
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>
Diffstat (limited to 'init')
| -rw-r--r-- | init/Kconfig | 15 |
1 files changed, 7 insertions, 8 deletions
diff --git a/init/Kconfig b/init/Kconfig index da6a91c4a05..4ad6de16323 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -523,9 +523,9 @@ config SLAB bool "SLAB" help 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 - slab allocator. + a slab allocator. config SLUB depends on EXPERIMENTAL && !ARCH_USES_SLAB_PAGE_STRUCT @@ -535,21 +535,20 @@ config SLUB instead of managing queues of cached objects (SLAB approach). Per cpu caching is realized using slabs of objects instead of queues of objects. SLUB can use memory efficiently - way and has enhanced diagnostics. + and has enhanced diagnostics. config SLOB # -# SLOB cannot support SMP because SLAB_DESTROY_BY_RCU does not work -# properly. +# SLOB does not support SMP because SLAB_DESTROY_BY_RCU is unsupported # depends on EMBEDDED && !SMP && !SPARSEMEM bool "SLOB (Simple Allocator)" help SLOB replaces the SLAB allocator with a drastically simpler allocator. SLOB is more space efficient that SLAB but does not - scale well (single lock for all operations) and is more susceptible - to fragmentation. SLOB it is a great choice to reduce - memory usage and code size for embedded systems. + scale well (single lock for all operations) and is also highly + susceptible to fragmentation. SLUB can accomplish a higher object + density. It is usually better to use SLUB instead of SLOB. endchoice |