linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Clark Williams <williams@redhat.com>
To: Pekka Enberg <penberg@kernel.org>
Cc: Christoph Lameter <cl@linux.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Joonsoo Kim <js1304@gmail.com>, Clark Williams <clark@redhat.com>,
	Glauber Costa <glommer@gmail.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: Tue, 18 Jun 2013 10:21:09 -0500	[thread overview]
Message-ID: <20130618102109.310f4ce1@riff.lan> (raw)
In-Reply-To: <0000013f57a5b278-d9104e1e-ccec-40ec-bd95-f8b0816a38d9-000000@email.amazonses.com>

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

On Tue, 18 Jun 2013 14:17:25 +0000
Christoph Lameter <cl@linux.com> wrote:

> On Tue, 18 Jun 2013, Pekka Enberg wrote:
> 
> > The changelog is way too vague. Numbers? Anyone who would want to
> > use this in real world scenarios, please speak up!
> 
> Steve?

Steve's out this morning so I'll take a stab at it.

This was an RT request. When we switched over to SLUB we saw an
immediate overall performance boost over SLAB but encountered some
249 microsecond latency spikes when testing on large systems
(40-core/256GB RAM). Latency traces showed that our spikes were
SLUB's cpu_partial processing in unfreeze_partials(). 

We hacked up a boot script that would traverse the /sys/kernel/slab
tree and write a zero to all the 'cpu_partial' entries (turning them
off) but asked Christoph if he had a way to configure cpu_partial
processing out, since running the script at boot did not actually catch
all instances of cpu_partial. 

I'm sure it would be better to actually do cpu_partial processing in
small chunks to avoid latency spikes in latency sensitive applications
but for the short-term it's just easier to turn it off. 

Clark

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2013-06-18 15:21 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 ` Christoph Lameter
2013-06-18  6:35   ` Pekka Enberg
2013-06-18 14:17     ` Christoph Lameter
2013-06-18 15:21       ` Clark Williams [this message]
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
     [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 19:55 ` [3.11 2/4] slob: Rework #ifdeffery in slab.h Christoph Lameter
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=20130618102109.310f4ce1@riff.lan \
    --to=williams@redhat.com \
    --cc=cl@linux.com \
    --cc=clark@redhat.com \
    --cc=glommer@gmail.com \
    --cc=js1304@gmail.com \
    --cc=linux-mm@kvack.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --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