From: Wanpeng Li <liwanp@linux.vnet.ibm.com>
To: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
Glauber Costa <glommer@parallels.com>,
linux-mm@kvack.org, David Rientjes <rientjes@google.com>
Subject: Re: [3.11 1/4] slub: Make cpu partial slab support configurable V2
Date: Thu, 20 Jun 2013 10:53:36 +0800 [thread overview]
Message-ID: <20130620025336.GA29876@hacker.(null)> (raw)
In-Reply-To: <20130620015056.GC13026@lge.com>
On Thu, Jun 20, 2013 at 10:50:56AM +0900, Joonsoo Kim wrote:
>On Wed, Jun 19, 2013 at 02:29:29PM +0000, Christoph Lameter wrote:
>> On Wed, 19 Jun 2013, Joonsoo Kim wrote:
>>
>> > How about maintaining cpu_partial when !CONFIG_SLUB_CPU_PARTIAL?
>> > It makes code less churn and doesn't have much overhead.
>> > At bottom, my implementation with cpu_partial is attached. It uses less '#ifdef'.
>>
>> Looks good. I am fine with it.
>>
>> Acked-by: Christoph Lameter <cl@linux.com>
>
>Thanks!
>
>Hello, Pekka.
>I attach a right formatted patch with acked by Christoph and
>signed off by me.
>
>It is based on v3.10-rc6 and top of a patch
>"slub: do not put a slab to cpu partial list when cpu_partial is 0".
>
>>
>> --
>> 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>
>
>
>-----------------8<-----------------------------------------------
>>From a3257adcff89fd89a7ecb26c1247eec511302807 Mon Sep 17 00:00:00 2001
>From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
>Date: Wed, 19 Jun 2013 14:05:52 +0900
>Subject: [PATCH] slub: Make cpu partial slab support configurable
>
>cpu partial support can introduce level of indeterminism that is not
>wanted in certain context (like a realtime kernel). Make it configurable.
>
>This patch is based on Christoph Lameter's
>"slub: Make cpu partial slab support configurable V2".
>
As you know, actually cpu_partial is the maximum number of objects kept
in the per cpu slab and cpu partial lists of a processor instead of
just the maximum number of objects kept in cpu partial lists of a
processor. The allocation will always fallback to slow path if not
config SLUB_CPU_PARTIAL, whether it will lead to more latency?
Regards,
Wanpeng Li
>Acked-by: Christoph Lameter <cl@linux.com>
>Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
>
>diff --git a/init/Kconfig b/init/Kconfig
>index 2d9b831..a7ec1ec 100644
>--- a/init/Kconfig
>+++ b/init/Kconfig
>@@ -1559,6 +1559,17 @@ config SLOB
>
> endchoice
>
>+config SLUB_CPU_PARTIAL
>+ default y
>+ depends on SLUB
>+ bool "SLUB per cpu partial cache"
>+ help
>+ Per cpu partial caches accellerate objects allocation and freeing
>+ that is local to a processor at the price of more indeterminism
>+ in the latency of the free. On overflow these caches will be cleared
>+ which requires the taking of locks that may cause latency spikes.
>+ Typically one would choose no for a realtime system.
>+
> config MMAP_ALLOW_UNINITIALIZED
> bool "Allow mmapped anonymous memory to be uninitialized"
> depends on EXPERT && !MMU
>diff --git a/mm/slub.c b/mm/slub.c
>index 7033b4f..a670d22 100644
>--- a/mm/slub.c
>+++ b/mm/slub.c
>@@ -123,6 +123,15 @@ static inline int kmem_cache_debug(struct kmem_cache *s)
> #endif
> }
>
>+static inline bool kmem_cache_has_cpu_partial(struct kmem_cache *s)
>+{
>+#ifdef CONFIG_SLUB_CPU_PARTIAL
>+ return !kmem_cache_debug(s);
>+#else
>+ return false;
>+#endif
>+}
>+
> /*
> * Issues still to be resolved:
> *
>@@ -1573,7 +1582,8 @@ static void *get_partial_node(struct kmem_cache *s, struct kmem_cache_node *n,
> put_cpu_partial(s, page, 0);
> stat(s, CPU_PARTIAL_NODE);
> }
>- if (kmem_cache_debug(s) || available > s->cpu_partial / 2)
>+ if (!kmem_cache_has_cpu_partial(s)
>+ || available > s->cpu_partial / 2)
> break;
>
> }
>@@ -1884,6 +1894,7 @@ redo:
> static void unfreeze_partials(struct kmem_cache *s,
> struct kmem_cache_cpu *c)
> {
>+#ifdef CONFIG_SLUB_CPU_PARTIAL
> struct kmem_cache_node *n = NULL, *n2 = NULL;
> struct page *page, *discard_page = NULL;
>
>@@ -1938,6 +1949,7 @@ static void unfreeze_partials(struct kmem_cache *s,
> discard_slab(s, page);
> stat(s, FREE_SLAB);
> }
>+#endif
> }
>
> /*
>@@ -1951,6 +1963,7 @@ static void unfreeze_partials(struct kmem_cache *s,
> */
> static void put_cpu_partial(struct kmem_cache *s, struct page *page, int drain)
> {
>+#ifdef CONFIG_SLUB_CPU_PARTIAL
> struct page *oldpage;
> int pages;
> int pobjects;
>@@ -1990,6 +2003,7 @@ static void put_cpu_partial(struct kmem_cache *s, struct page *page, int drain)
> page->next = oldpage;
>
> } while (this_cpu_cmpxchg(s->cpu_slab->partial, oldpage, page) != oldpage);
>+#endif
> }
>
> static inline void flush_slab(struct kmem_cache *s, struct kmem_cache_cpu *c)
>@@ -2498,7 +2512,7 @@ static void __slab_free(struct kmem_cache *s, struct page *page,
> new.inuse--;
> if ((!new.inuse || !prior) && !was_frozen) {
>
>- if (!kmem_cache_debug(s) && !prior)
>+ if (kmem_cache_has_cpu_partial(s) && !prior)
>
> /*
> * Slab was on no list before and will be partially empty
>@@ -3062,7 +3076,7 @@ static int kmem_cache_open(struct kmem_cache *s, unsigned long flags)
> * per node list when we run out of per cpu objects. We only fetch 50%
> * to keep some capacity around for frees.
> */
>- if (kmem_cache_debug(s))
>+ if (!kmem_cache_has_cpu_partial(s))
> s->cpu_partial = 0;
> else if (s->size >= PAGE_SIZE)
> s->cpu_partial = 2;
>@@ -4459,7 +4473,7 @@ static ssize_t cpu_partial_store(struct kmem_cache *s, const char *buf,
> err = strict_strtoul(buf, 10, &objects);
> if (err)
> return err;
>- if (objects && kmem_cache_debug(s))
>+ if (objects && !kmem_cache_has_cpu_partial(s))
> return -EINVAL;
>
> s->cpu_partial = objects;
>--
>1.7.9.5
>
>--
>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>
--
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:[~2013-06-20 2:53 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20130614195500.373711648@linux.com>
2013-06-14 19:55 ` [3.11 2/4] slob: Rework #ifdeffery in slab.h Christoph Lameter
2013-06-14 19:55 ` [3.11 1/4] slub: Make cpu partial slab support configurable V2 Christoph Lameter
2013-06-18 6:35 ` Pekka Enberg
2013-06-18 14:17 ` Christoph Lameter
2013-06-18 15:21 ` Clark Williams
2013-06-18 15:25 ` Pekka Enberg
2013-06-25 14:24 ` Steven Rostedt
2013-07-01 18:16 ` Christoph Lameter
2013-07-02 15:09 ` Clark Williams
2013-07-02 16:47 ` Christoph Lameter
2013-07-02 16:53 ` Clark Williams
2013-07-17 2:46 ` Steven Rostedt
2013-07-17 7:04 ` Pekka Enberg
2013-07-17 12:23 ` Steven Rostedt
2013-07-17 15:04 ` Christoph Lameter
2013-07-17 15:15 ` Steven Rostedt
2013-07-17 15:24 ` Steven Rostedt
2013-06-19 5:22 ` Joonsoo Kim
2013-06-19 14:29 ` Christoph Lameter
2013-06-20 1:50 ` Joonsoo Kim
2013-06-20 2:53 ` Wanpeng Li
2013-06-20 2:53 ` Wanpeng Li [this message]
[not found] ` <51c26ebd.e842320a.5dc1.ffffedfcSMTPIN_ADDED_BROKEN@mx.google.com>
2013-06-20 5:45 ` Joonsoo Kim
2013-06-20 5:50 ` Joonsoo Kim
2013-07-07 16:10 ` Pekka Enberg
2013-06-14 20:06 ` [3.11 3/4] Move kmalloc_node functions to common code Christoph Lameter
2013-06-18 15:38 ` Pekka Enberg
2013-06-18 17:02 ` Christoph Lameter
2013-07-07 16:14 ` Pekka Enberg
2013-07-08 18:55 ` Christoph Lameter
2013-06-19 6:30 ` Joonsoo Kim
2013-06-19 14:33 ` Christoph Lameter
2013-06-20 1:51 ` Joonsoo Kim
2013-06-14 20:06 ` [3.11 4/4] Move kmalloc definitions to slab.h 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='20130620025336.GA29876@hacker.(null)' \
--to=liwanp@linux.vnet.ibm.com \
--cc=cl@linux.com \
--cc=glommer@parallels.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.