提交 34013886 编写于 作者: C Christoph Lameter 提交者: Linus Torvalds

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: NChristoph Lameter <clameter@sgi.com>
Cc: Matt Mackall <mpm@selenic.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
上级 7ae439ce
......@@ -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
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册