linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
> 

  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).