linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: clameter@sgi.com
To: Nishanth Aravamudan <nacc@us.ibm.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>, linux-mm@kvack.org
Subject: [RFC 11/13] SLUB: Ensure that the # object per slabs stays low enough.
Date: Thu, 14 Jun 2007 00:50:37 -0700	[thread overview]
Message-ID: <20070614075336.635263920@sgi.com> (raw)
In-Reply-To: <20070614075026.607300756@sgi.com>

[-- Attachment #1: slub_oversize --]
[-- Type: text/plain, Size: 2663 bytes --]

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 reduce TLB pressure.

Signed-off-by: Christoph Lameter <clameter@sgi.com>

---
 mm/slub.c |   21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)

Index: vps/mm/slub.c
===================================================================
--- vps.orig/mm/slub.c	2007-06-12 15:58:35.000000000 -0700
+++ vps/mm/slub.c	2007-06-12 16:04:01.000000000 -0700
@@ -212,6 +212,11 @@ static inline void ClearSlabDebug(struct
 #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 */
 
@@ -1751,8 +1756,17 @@ static inline int slab_order(int size, i
 {
 	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++) {
 
@@ -1766,6 +1780,9 @@ static inline int slab_order(int size, i
 		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;
@@ -2048,7 +2065,7 @@ static int calculate_sizes(struct kmem_c
 	 * 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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2007-06-14  7:50 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-14  7:50 [RFC 00/13] RFC memoryless node handling fixes clameter
2007-06-14  7:50 ` [RFC 01/13] NUMA: introduce node_memory_map clameter
2007-06-14  7:50 ` [RFC 02/13] Fix MPOL_INTERLEAVE behavior for memoryless nodes clameter
2007-06-14  7:50 ` [RFC 03/13] OOM: use the node_memory_map instead of constructing one on the fly clameter
2007-06-14  7:50 ` [RFC 04/13] Memoryless Nodes: No need for kswapd clameter
2007-06-14  7:50 ` [RFC 05/13] Memoryless Node: Slab support clameter
2007-06-14  7:50 ` [RFC 06/13] Memoryless nodes: SLUB support clameter
2007-06-14  7:50 ` [RFC 07/13] Uncached allocator: Handle memoryless nodes clameter
2007-06-14  7:50 ` [RFC 08/13] Memoryless node: Allow profiling data to fall back to other nodes clameter
2007-06-14  7:50 ` [RFC 09/13] Memoryless nodes: Update memory policy and page migration clameter
2007-06-14  7:50 ` [RFC 10/13] Memoryless nodes: Fix GFP_THISNODE behavior clameter
2007-06-14 16:07   ` Nishanth Aravamudan
2007-06-14 16:13     ` Christoph Lameter
2007-06-18 16:47     ` Nishanth Aravamudan
2007-06-14  7:50 ` clameter [this message]
2007-06-14  7:50 ` [RFC 12/13] SLUB: minimum alignment fixes clameter
2007-06-14  7:56   ` Christoph Lameter
2007-06-14  7:50 ` [RFC 13/13] I finally found a way to get rid of the nasty list of comparisions in slub_def.h. ilog2 seems to work right for constants clameter
2007-06-14  7:57   ` Christoph Lameter
2007-06-14 14:24 ` [RFC 00/13] RFC memoryless node handling fixes Nishanth Aravamudan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070614075336.635263920@sgi.com \
    --to=clameter@sgi.com \
    --cc=Lee.Schermerhorn@hp.com \
    --cc=linux-mm@kvack.org \
    --cc=nacc@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox