From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Christoph Lameter <cl@linux.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Steven Rostedt <rostedt@goodmis.org>,
LKML <linux-kernel@vger.kernel.org>,
RT <linux-rt-users@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Clark Williams <clark@redhat.com>,
Pekka Enberg <penberg@kernel.org>
Subject: Re: [RT LATENCY] 249 microsecond latency caused by slub's unfreeze_partials() code.
Date: Mon, 1 Apr 2013 17:46:03 -0400 [thread overview]
Message-ID: <515A001B.4010009@windriver.com> (raw)
In-Reply-To: <0000013dc63a9086-7d10c4a8-748c-4e19-829a-856d8d42c8eb-000000@email.amazonses.com>
On 13-04-01 11:32 AM, Christoph Lameter wrote:
[...]
> @@ -4583,6 +4615,7 @@ static ssize_t min_partial_store(struct
> }
> SLAB_ATTR(min_partial);
>
> +#ifdef CONFIG_CPU_PARTIAL
Above causes build failures when stats are on, because the
name is wrong and hence is never defined, and ....
> static ssize_t cpu_partial_show(struct kmem_cache *s, char *buf)
> {
> return sprintf(buf, "%u\n", s->cpu_partial);
> @@ -4605,6 +4638,7 @@ static ssize_t cpu_partial_store(struct
> return length;
> }
> SLAB_ATTR(cpu_partial);
> +#endif
>
> static ssize_t ctor_show(struct kmem_cache *s, char *buf)
> {
> @@ -4644,6 +4678,7 @@ static ssize_t objects_partial_show(stru
> }
> SLAB_ATTR_RO(objects_partial);
>
> +#ifdef CONFIG_SLUB_CPU_PARTIAL
> static ssize_t slabs_cpu_partial_show(struct kmem_cache *s, char *buf)
> {
> int objects = 0;
> @@ -4674,6 +4709,7 @@ static ssize_t slabs_cpu_partial_show(st
> return len + sprintf(buf + len, "\n");
> }
> SLAB_ATTR_RO(slabs_cpu_partial);
> +#endif
>
> static ssize_t reclaim_account_show(struct kmem_cache *s, char *buf)
> {
> @@ -4997,11 +5033,13 @@ STAT_ATTR(DEACTIVATE_BYPASS, deactivate_
> STAT_ATTR(ORDER_FALLBACK, order_fallback);
> STAT_ATTR(CMPXCHG_DOUBLE_CPU_FAIL, cmpxchg_double_cpu_fail);
> STAT_ATTR(CMPXCHG_DOUBLE_FAIL, cmpxchg_double_fail);
> +#ifdef CONFIG_CPU_PARTIAL
...the same here, and ...
> STAT_ATTR(CPU_PARTIAL_ALLOC, cpu_partial_alloc);
> STAT_ATTR(CPU_PARTIAL_FREE, cpu_partial_free);
> STAT_ATTR(CPU_PARTIAL_NODE, cpu_partial_node);
> STAT_ATTR(CPU_PARTIAL_DRAIN, cpu_partial_drain);
> #endif
> +#endif
>
> static struct attribute *slab_attrs[] = {
> &slab_size_attr.attr,
> @@ -5009,7 +5047,9 @@ static struct attribute *slab_attrs[] =
> &objs_per_slab_attr.attr,
> &order_attr.attr,
> &min_partial_attr.attr,
> +#ifdef CONFIG_CPU_PARTIAL
...here too. All should be CONFIG_SLUB_CPU_PARTIAL
Thanks,
Paul.
--
> &cpu_partial_attr.attr,
> +#endif
> &objects_attr.attr,
> &objects_partial_attr.attr,
> &partial_attr.attr,
> @@ -5022,7 +5062,9 @@ static struct attribute *slab_attrs[] =
> &destroy_by_rcu_attr.attr,
> &shrink_attr.attr,
> &reserved_attr.attr,
> +#ifdef CONFIG_SLUB_CPU_PARTIAL
> &slabs_cpu_partial_attr.attr,
> +#endif
> #ifdef CONFIG_SLUB_DEBUG
> &total_objects_attr.attr,
> &slabs_attr.attr,
> @@ -5064,11 +5106,13 @@ static struct attribute *slab_attrs[] =
> &order_fallback_attr.attr,
> &cmpxchg_double_fail_attr.attr,
> &cmpxchg_double_cpu_fail_attr.attr,
> +#ifdef CONFIG_SLUB_CPU_PARTIAL
> &cpu_partial_alloc_attr.attr,
> &cpu_partial_free_attr.attr,
> &cpu_partial_node_attr.attr,
> &cpu_partial_drain_attr.attr,
> #endif
> +#endif
> #ifdef CONFIG_FAILSLAB
> &failslab_attr.attr,
> #endif
> Index: linux/init/Kconfig
> ===================================================================
> --- linux.orig/init/Kconfig 2013-04-01 10:27:05.908964674 -0500
> +++ linux/init/Kconfig 2013-04-01 10:31:46.497863625 -0500
> @@ -1514,6 +1514,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
>
next prev parent reply other threads:[~2013-04-01 21:46 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-21 22:55 [RT LATENCY] 249 microsecond latency caused by slub's unfreeze_partials() code Steven Rostedt
2013-03-22 15:41 ` Christoph Lameter
2013-03-23 3:51 ` Steven Rostedt
2013-03-25 14:34 ` Christoph Lameter
2013-03-25 15:57 ` Steven Rostedt
2013-03-25 16:13 ` Steven Rostedt
2013-03-25 17:51 ` Christoph Lameter
2013-03-25 18:03 ` Steven Rostedt
2013-03-25 18:27 ` Christoph Lameter
2013-03-25 18:32 ` Steven Rostedt
2013-03-27 2:59 ` Joonsoo Kim
2013-03-27 3:30 ` Steven Rostedt
2013-03-27 6:13 ` Joonsoo Kim
2013-03-28 17:29 ` Christoph Lameter
2013-04-08 12:25 ` Steven Rostedt
[not found] ` <alpine.DEB.2.02.1303281227520.16200@gentwo.org>
2013-03-28 17:30 ` Christoph Lameter
2013-03-29 2:43 ` Paul Gortmaker
2013-04-01 15:32 ` Christoph Lameter
2013-04-01 16:06 ` Paul Gortmaker
2013-04-02 0:07 ` Paul Gortmaker
2013-04-01 21:46 ` Paul Gortmaker [this message]
2013-04-02 1:37 ` Joonsoo Kim
[not found] ` <alpine.DEB.2.02.1304011025550.12690@gentwo.org>
2013-04-01 15:33 ` Christoph Lameter
2013-04-02 0:42 ` Joonsoo Kim
2013-04-02 6:48 ` Pekka Enberg
2013-04-02 19:25 ` Christoph Lameter
2013-04-04 0:58 ` Joonsoo Kim
2013-04-04 13:53 ` Christoph Lameter
2013-04-05 2:05 ` Joonsoo Kim
2013-04-05 14:35 ` Christoph Lameter
2013-04-08 12:32 ` Steven Rostedt
2013-04-10 6:31 ` Pekka Enberg
2013-04-10 7:31 ` Joonsoo Kim
2013-04-10 14:00 ` Christoph Lameter
2013-04-10 14:09 ` Steven Rostedt
2013-04-11 16:05 ` Steven Rostedt
2013-04-11 16:42 ` Christoph Lameter
2013-04-12 6:48 ` Pekka Enberg
2013-05-28 14:39 ` Steven Rostedt
2013-05-28 16:22 ` Christoph Lameter
[not found] ` <alpine.DEB.2.02.1305281121420.1627@gentwo.org>
2013-05-28 18:24 ` Christoph Lameter
2013-06-03 15:28 ` JoonSoo Kim
2013-06-03 19:20 ` Christoph Lameter
2013-06-04 22:21 ` JoonSoo Kim
2013-06-05 14:06 ` Christoph Lameter
2013-06-05 14:09 ` Christoph Lameter
2013-06-03 20:41 ` Christoph Lameter
2013-03-26 16:52 ` Steven Rostedt
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=515A001B.4010009@windriver.com \
--to=paul.gortmaker@windriver.com \
--cc=cl@linux.com \
--cc=clark@redhat.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=penberg@kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/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;
as well as URLs for NNTP newsgroup(s).