]> pilppa.com Git - linux-2.6-omap-h63xx.git/commitdiff
Fix spellings of slab allocator section in init/Kconfig
authorChristoph Lameter <clameter@sgi.com>
Wed, 9 May 2007 09:32:47 +0000 (02:32 -0700)
committerLinus Torvalds <torvalds@woody.linux-foundation.org>
Wed, 9 May 2007 19:30:46 +0000 (12:30 -0700)
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>
init/Kconfig

index da6a91c4a0517baa1f7a4e1ba996e34b5dd7cecf..4ad6de163238f2bfc252e0cc9ef6c6dc2548e34b 100644 (file)
@@ -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.
+         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