From: Christoph Lameter <cl@linux-foundation.org>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Mel Gorman <mel@csn.ul.ie>, Nick Piggin <nickpiggin@yahoo.com.au>,
Nick Piggin <npiggin@suse.de>,
Linux Memory Management List <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Lin Ming <ming.m.lin@intel.com>,
"Zhang, Yanmin" <yanmin_zhang@linux.intel.com>
Subject: Re: [patch] SLQB slab allocator (try 2)
Date: Tue, 17 Feb 2009 12:05:07 -0500 (EST) [thread overview]
Message-ID: <alpine.DEB.1.10.0902171204070.15929@qirst.com> (raw)
In-Reply-To: <1234890096.11511.6.camel@penberg-laptop>
Well yes you missed two locations (kmalloc_caches array has to be
redimensioned) and I also was writing the same patch...
Here is mine:
Subject: SLUB: Do not pass 8k objects through to the page allocator
Increase the maximum object size in SLUB so that 8k objects are not
passed through to the page allocator anymore. The network stack uses 8k
objects for performance critical operations.
Signed-off-by: Christoph Lameter <cl@linux-foundation.org>
Index: linux-2.6/include/linux/slub_def.h
===================================================================
--- linux-2.6.orig/include/linux/slub_def.h 2009-02-17 10:45:51.000000000 -0600
+++ linux-2.6/include/linux/slub_def.h 2009-02-17 11:06:53.000000000 -0600
@@ -121,10 +121,21 @@
#define KMALLOC_SHIFT_LOW ilog2(KMALLOC_MIN_SIZE)
/*
+ * Maximum kmalloc object size handled by SLUB. Larger object allocations
+ * are passed through to the page allocator. The page allocator "fastpath"
+ * is relatively slow so we need this value sufficiently high so that
+ * performance critical objects are allocated through the SLUB fastpath.
+ *
+ * This should be dropped to PAGE_SIZE / 2 once the page allocator
+ * "fastpath" becomes competitive with the slab allocator fastpaths.
+ */
+#define SLUB_MAX_SIZE (2 * PAGE_SIZE)
+
+/*
* We keep the general caches in an array of slab caches that are used for
* 2^x bytes of allocations.
*/
-extern struct kmem_cache kmalloc_caches[PAGE_SHIFT + 1];
+extern struct kmem_cache kmalloc_caches[PAGE_SHIFT + 2];
/*
* Sorry that the following has to be that ugly but some versions of GCC
@@ -212,7 +223,7 @@
static __always_inline void *kmalloc(size_t size, gfp_t flags)
{
if (__builtin_constant_p(size)) {
- if (size > PAGE_SIZE)
+ if (size > SLUB_MAX_SIZE)
return kmalloc_large(size, flags);
if (!(flags & SLUB_DMA)) {
@@ -234,7 +245,7 @@
static __always_inline void *kmalloc_node(size_t size, gfp_t flags, int node)
{
if (__builtin_constant_p(size) &&
- size <= PAGE_SIZE && !(flags & SLUB_DMA)) {
+ size <= SLUB_MAX_SIZE && !(flags & SLUB_DMA)) {
struct kmem_cache *s = kmalloc_slab(size);
if (!s)
Index: linux-2.6/mm/slub.c
===================================================================
--- linux-2.6.orig/mm/slub.c 2009-02-17 10:49:47.000000000 -0600
+++ linux-2.6/mm/slub.c 2009-02-17 10:58:14.000000000 -0600
@@ -2475,7 +2475,7 @@
* Kmalloc subsystem
*******************************************************************/
-struct kmem_cache kmalloc_caches[PAGE_SHIFT + 1] __cacheline_aligned;
+struct kmem_cache kmalloc_caches[PAGE_SHIFT + 2] __cacheline_aligned;
EXPORT_SYMBOL(kmalloc_caches);
static int __init setup_slub_min_order(char *str)
@@ -2658,7 +2658,7 @@
{
struct kmem_cache *s;
- if (unlikely(size > PAGE_SIZE))
+ if (unlikely(size > SLUB_MAX_SIZE))
return kmalloc_large(size, flags);
s = get_slab(size, flags);
@@ -2686,7 +2686,7 @@
{
struct kmem_cache *s;
- if (unlikely(size > PAGE_SIZE))
+ if (unlikely(size > SLUB_MAX_SIZE))
return kmalloc_large_node(size, flags, node);
s = get_slab(size, flags);
@@ -3223,7 +3223,7 @@
{
struct kmem_cache *s;
- if (unlikely(size > PAGE_SIZE))
+ if (unlikely(size > SLUB_MAX_SIZE))
return kmalloc_large(size, gfpflags);
s = get_slab(size, gfpflags);
@@ -3239,7 +3239,7 @@
{
struct kmem_cache *s;
- if (unlikely(size > PAGE_SIZE))
+ if (unlikely(size > SLUB_MAX_SIZE))
return kmalloc_large_node(size, gfpflags, node);
s = get_slab(size, gfpflags);
--
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>
next prev parent reply other threads:[~2009-02-17 17:13 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-23 15:46 Nick Piggin
2009-01-24 2:38 ` Zhang, Yanmin
2009-01-26 8:48 ` Pekka Enberg
2009-01-26 9:07 ` Peter Zijlstra
2009-01-26 9:10 ` Peter Zijlstra
2009-01-26 17:22 ` Christoph Lameter
2009-01-27 9:07 ` Peter Zijlstra
2009-01-27 20:21 ` Christoph Lameter
2009-02-03 2:04 ` Nick Piggin
2009-02-03 10:12 ` Mel Gorman
2009-02-03 10:36 ` Nick Piggin
2009-02-03 11:22 ` Mel Gorman
2009-02-03 11:26 ` Mel Gorman
2009-02-04 6:48 ` Nick Piggin
2009-02-04 15:27 ` Mel Gorman
2009-02-05 3:59 ` Nick Piggin
2009-02-05 13:49 ` Mel Gorman
2009-02-16 18:42 ` Mel Gorman
2009-02-16 19:17 ` Pekka Enberg
2009-02-16 19:41 ` Mel Gorman
2009-02-16 19:43 ` Pekka Enberg
2009-02-17 1:06 ` Zhang, Yanmin
2009-02-17 16:20 ` Christoph Lameter
2009-02-17 17:01 ` Pekka Enberg
2009-02-17 17:05 ` Christoph Lameter [this message]
2009-02-17 17:24 ` Pekka Enberg
2009-02-17 18:11 ` Johannes Weiner
2009-02-17 19:43 ` Pekka Enberg
2009-02-17 20:04 ` Christoph Lameter
2009-02-18 0:48 ` KOSAKI Motohiro
2009-02-18 8:09 ` Pekka Enberg
2009-02-19 0:05 ` KOSAKI Motohiro
2009-02-19 9:16 ` Pekka Enberg
2009-02-19 12:51 ` KOSAKI Motohiro
2009-02-19 13:15 ` Pekka Enberg
2009-02-19 13:49 ` KOSAKI Motohiro
2009-02-19 14:19 ` Christoph Lameter
2009-02-18 1:05 ` Zhang, Yanmin
2009-02-18 7:48 ` Pekka Enberg
2009-02-18 8:43 ` Zhang, Yanmin
2009-02-18 9:01 ` Pekka Enberg
2009-02-18 9:19 ` Zhang, Yanmin
2009-02-19 8:40 ` Pekka Enberg
2009-02-16 19:25 ` Pekka Enberg
2009-02-16 19:44 ` Mel Gorman
2009-02-16 19:42 ` Pekka Enberg
2009-02-03 11:28 ` Mel Gorman
2009-02-03 11:50 ` Nick Piggin
2009-02-03 12:01 ` Mel Gorman
2009-02-03 12:07 ` Nick Piggin
2009-02-03 12:26 ` Mel Gorman
2009-02-04 15:49 ` Christoph Lameter
2009-02-04 15:48 ` Christoph Lameter
2009-02-03 18:58 ` Pekka Enberg
2009-02-04 16:06 ` Christoph Lameter
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=alpine.DEB.1.10.0902171204070.15929@qirst.com \
--to=cl@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=ming.m.lin@intel.com \
--cc=nickpiggin@yahoo.com.au \
--cc=npiggin@suse.de \
--cc=penberg@cs.helsinki.fi \
--cc=yanmin_zhang@linux.intel.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