Gitweb:     
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6300ea75031e7aebfe3331245b7f750d82621223
Commit:     6300ea75031e7aebfe3331245b7f750d82621223
Parent:     68dff6a9af9f27df5aeee6d0339818b0e36c1b51
Author:     Christoph Lameter <[EMAIL PROTECTED]>
AuthorDate: Tue Jul 17 04:03:20 2007 -0700
Committer:  Linus Torvalds <[EMAIL PROTECTED]>
CommitDate: Tue Jul 17 10:23:01 2007 -0700

    SLUB: ensure that the number of objects per slab stays low for high orders
    
    Currently SLUB has no provision to deal with too high page orders that may
    be specified on the kernel boot line.  If an order higher than 6 (on a 4k
    platform) is generated then we will BUG() because slabs get more than 65535
    objects.
    
    Add some logic that decreases order for slabs that have too many objects.
    This allow booting with slab sizes up to MAX_ORDER.
    
    For example
    
        slub_min_order=10
    
    will boot with a default slab size of 4M and reduce slab sizes for small
    object sizes to lower orders if the number of objects becomes too big.
    Large slab sizes like that allow a concentration of objects of the same
    slab cache under as few as possible TLB entries and thus potentially
    reduces TLB pressure.
    
    Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
    Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
    Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
---
 mm/slub.c |   21 +++++++++++++++++++--
 1 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/mm/slub.c b/mm/slub.c
index a5832f8..03ae549 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -205,6 +205,11 @@ static inline void ClearSlabDebug(struct page *page)
 #define ARCH_SLAB_MINALIGN __alignof__(unsigned long long)
 #endif
 
+/*
+ * The page->inuse field is 16 bit thus we have this limitation
+ */
+#define MAX_OBJECTS_PER_SLAB 65535
+
 /* Internal SLUB flags */
 #define __OBJECT_POISON 0x80000000     /* Poison object */
 
@@ -1736,8 +1741,17 @@ static inline int slab_order(int size, int min_objects,
 {
        int order;
        int rem;
+       int min_order = slub_min_order;
 
-       for (order = max(slub_min_order,
+       /*
+        * If we would create too many object per slab then reduce
+        * the slab order even if it goes below slub_min_order.
+        */
+       while (min_order > 0 &&
+               (PAGE_SIZE << min_order) >= MAX_OBJECTS_PER_SLAB * size)
+                       min_order--;
+
+       for (order = max(min_order,
                                fls(min_objects * size - 1) - PAGE_SHIFT);
                        order <= max_order; order++) {
 
@@ -1751,6 +1765,9 @@ static inline int slab_order(int size, int min_objects,
                if (rem <= slab_size / fract_leftover)
                        break;
 
+               /* If the next size is too high then exit now */
+               if (slab_size * 2 >= MAX_OBJECTS_PER_SLAB * size)
+                       break;
        }
 
        return order;
@@ -2037,7 +2054,7 @@ static int calculate_sizes(struct kmem_cache *s)
         * The page->inuse field is only 16 bit wide! So we cannot have
         * more than 64k objects per slab.
         */
-       if (!s->objects || s->objects > 65535)
+       if (!s->objects || s->objects > MAX_OBJECTS_PER_SLAB)
                return 0;
        return 1;
 
-
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  http://vger.kernel.org/majordomo-info.html

Reply via email to