Commit:     34013886ef47ea72e412beb04558431b57a68d51
Parent:     7ae439ce0c01d7db0c70d1542985969e95ef750d
Author:     Christoph Lameter <[EMAIL PROTECTED]>
AuthorDate: Wed May 9 02:32:47 2007 -0700
Committer:  Linus Torvalds <[EMAIL PROTECTED]>
CommitDate: Wed May 9 12:30:46 2007 -0700

    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 <[EMAIL PROTECTED]>
    Cc: Matt Mackall <[EMAIL PROTECTED]>
    Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
    Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
 init/Kconfig |   15 +++++++--------
 1 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index da6a91c..4ad6de1 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -523,9 +523,9 @@ config SLAB
        bool "SLAB"
          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
@@ -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)"
           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.
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at

Reply via email to