From: Pekka Enberg <penberg@kernel.org>
To: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <cl@linux.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
hughd@google.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [GIT PULL] Lockless SLUB slowpaths for v3.1-rc1
Date: Mon, 01 Aug 2011 08:08:26 +0300 [thread overview]
Message-ID: <1312175306.24862.103.camel@jaguar> (raw)
In-Reply-To: <alpine.DEB.2.00.1107311426001.944@chino.kir.corp.google.com>
On Sun, 2011-07-31 at 14:55 -0700, David Rientjes wrote:
> On Sun, 31 Jul 2011, Pekka Enberg wrote:
>
> > > And although slub is definitely heading in the right direction regarding
> > > the netperf benchmark, it's still a non-starter for anybody using large
> > > NUMA machines for networking performance. On my 16-core, 4 node, 64GB
> > > client/server machines running netperf TCP_RR with various thread counts
> > > for 60 seconds each on 3.0:
> > >
> > > threads SLUB SLAB diff
> > > 16 76345 74973 - 1.8%
> > > 32 116380 116272 - 0.1%
> > > 48 150509 153703 + 2.1%
> > > 64 187984 189750 + 0.9%
> > > 80 216853 224471 + 3.5%
> > > 96 236640 249184 + 5.3%
> > > 112 256540 275464 + 7.4%
> > > 128 273027 296014 + 8.4%
> > > 144 281441 314791 +11.8%
> > > 160 287225 326941 +13.8%
> >
> > That looks like a pretty nasty scaling issue. David, would it be
> > possible to see 'perf report' for the 160 case? [ Maybe even 'perf
> > annotate' for the interesting SLUB functions. ]
>
> More interesting than the perf report (which just shows kfree,
> kmem_cache_free, kmem_cache_alloc dominating) is the statistics that are
> exported by slub itself, it shows the "slab thrashing" issue that I
> described several times over the past few years. It's difficult to
> address because it's a result of slub's design. From the client side of
> 160 netperf TCP_RR threads for 60 seconds:
>
> cache alloc_fastpath alloc_slowpath
> kmalloc-256 10937512 (62.8%) 6490753
> kmalloc-1024 17121172 (98.3%) 303547
> kmalloc-4096 5526281 11910454 (68.3%)
>
> cache free_fastpath free_slowpath
> kmalloc-256 15469 17412798 (99.9%)
> kmalloc-1024 11604742 (66.6%) 5819973
> kmalloc-4096 14848 17421902 (99.9%)
>
> With those stats, there's no way that slub will even be able to compete
> with slab because it's not optimized for the slowpath.
Is the slowpath being hit more often with 160 vs 16 threads? As I said,
the problem you mentioned looks like a *scaling issue* to me which is
actually somewhat surprising. I knew that the slowpaths were slow but I
haven't seen this sort of data before.
I snipped the 'SLUB can never compete with SLAB' part because I'm
frankly more interested in raw data I can analyse myself. I'm hoping to
the per-CPU partial list patch queued for v3.2 soon and I'd be
interested to know how much I can expect that to help.
Pekka
WARNING: multiple messages have this Message-ID (diff)
From: Pekka Enberg <penberg@kernel.org>
To: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <cl@linux.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
hughd@google.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [GIT PULL] Lockless SLUB slowpaths for v3.1-rc1
Date: Mon, 01 Aug 2011 08:08:26 +0300 [thread overview]
Message-ID: <1312175306.24862.103.camel@jaguar> (raw)
In-Reply-To: <alpine.DEB.2.00.1107311426001.944@chino.kir.corp.google.com>
On Sun, 2011-07-31 at 14:55 -0700, David Rientjes wrote:
> On Sun, 31 Jul 2011, Pekka Enberg wrote:
>
> > > And although slub is definitely heading in the right direction regarding
> > > the netperf benchmark, it's still a non-starter for anybody using large
> > > NUMA machines for networking performance. On my 16-core, 4 node, 64GB
> > > client/server machines running netperf TCP_RR with various thread counts
> > > for 60 seconds each on 3.0:
> > >
> > > threads SLUB SLAB diff
> > > 16 76345 74973 - 1.8%
> > > 32 116380 116272 - 0.1%
> > > 48 150509 153703 + 2.1%
> > > 64 187984 189750 + 0.9%
> > > 80 216853 224471 + 3.5%
> > > 96 236640 249184 + 5.3%
> > > 112 256540 275464 + 7.4%
> > > 128 273027 296014 + 8.4%
> > > 144 281441 314791 +11.8%
> > > 160 287225 326941 +13.8%
> >
> > That looks like a pretty nasty scaling issue. David, would it be
> > possible to see 'perf report' for the 160 case? [ Maybe even 'perf
> > annotate' for the interesting SLUB functions. ]
>
> More interesting than the perf report (which just shows kfree,
> kmem_cache_free, kmem_cache_alloc dominating) is the statistics that are
> exported by slub itself, it shows the "slab thrashing" issue that I
> described several times over the past few years. It's difficult to
> address because it's a result of slub's design. From the client side of
> 160 netperf TCP_RR threads for 60 seconds:
>
> cache alloc_fastpath alloc_slowpath
> kmalloc-256 10937512 (62.8%) 6490753
> kmalloc-1024 17121172 (98.3%) 303547
> kmalloc-4096 5526281 11910454 (68.3%)
>
> cache free_fastpath free_slowpath
> kmalloc-256 15469 17412798 (99.9%)
> kmalloc-1024 11604742 (66.6%) 5819973
> kmalloc-4096 14848 17421902 (99.9%)
>
> With those stats, there's no way that slub will even be able to compete
> with slab because it's not optimized for the slowpath.
Is the slowpath being hit more often with 160 vs 16 threads? As I said,
the problem you mentioned looks like a *scaling issue* to me which is
actually somewhat surprising. I knew that the slowpaths were slow but I
haven't seen this sort of data before.
I snipped the 'SLUB can never compete with SLAB' part because I'm
frankly more interested in raw data I can analyse myself. I'm hoping to
the per-CPU partial list patch queued for v3.2 soon and I'd be
interested to know how much I can expect that to help.
Pekka
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-08-01 5:08 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-28 22:47 [GIT PULL] Lockless SLUB slowpaths for v3.1-rc1 Pekka Enberg
2011-07-28 22:47 ` Pekka Enberg
2011-07-29 15:04 ` Christoph Lameter
2011-07-29 15:04 ` Christoph Lameter
2011-07-29 23:18 ` Andi Kleen
2011-07-29 23:18 ` Andi Kleen
2011-07-30 6:33 ` Eric Dumazet
2011-07-30 6:33 ` Eric Dumazet
2011-07-31 18:50 ` David Rientjes
2011-07-31 18:50 ` David Rientjes
2011-07-31 20:24 ` David Rientjes
2011-07-31 20:24 ` David Rientjes
2011-07-31 20:45 ` Pekka Enberg
2011-07-31 20:45 ` Pekka Enberg
2011-07-31 21:55 ` David Rientjes
2011-07-31 21:55 ` David Rientjes
2011-08-01 5:08 ` Pekka Enberg [this message]
2011-08-01 5:08 ` Pekka Enberg
2011-08-01 10:02 ` David Rientjes
2011-08-01 10:02 ` David Rientjes
2011-08-01 12:45 ` Pekka Enberg
2011-08-01 12:45 ` Pekka Enberg
2011-08-02 2:43 ` David Rientjes
2011-08-02 2:43 ` David Rientjes
2011-08-01 12:06 ` Pekka Enberg
2011-08-01 12:06 ` Pekka Enberg
2011-08-01 15:55 ` Christoph Lameter
2011-08-01 15:55 ` Christoph Lameter
2011-08-02 4:05 ` David Rientjes
2011-08-02 4:05 ` David Rientjes
2011-08-02 14:15 ` Christoph Lameter
2011-08-02 14:15 ` Christoph Lameter
2011-08-02 16:24 ` David Rientjes
2011-08-02 16:24 ` David Rientjes
2011-08-02 16:36 ` Christoph Lameter
2011-08-02 16:36 ` Christoph Lameter
2011-08-02 20:02 ` David Rientjes
2011-08-02 20:02 ` David Rientjes
2011-08-03 14:09 ` Christoph Lameter
2011-08-03 14:09 ` Christoph Lameter
2011-08-08 20:04 ` David Rientjes
2011-08-08 20:04 ` David Rientjes
2011-07-30 18:27 ` Linus Torvalds
2011-07-30 18:27 ` Linus Torvalds
2011-07-30 18:32 ` Linus Torvalds
2011-07-30 18:32 ` Linus Torvalds
2011-07-31 17:39 ` Andi Kleen
2011-07-31 17:39 ` Andi Kleen
2011-08-01 0:22 ` KAMEZAWA Hiroyuki
2011-08-01 0:22 ` KAMEZAWA Hiroyuki
2011-07-31 18:11 ` David Rientjes
2011-07-31 18:11 ` David Rientjes
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=1312175306.24862.103.camel@jaguar \
--to=penberg@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
--cc=torvalds@linux-foundation.org \
/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.