From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: brouer@redhat.com, Dave Chinner <dchinner@redhat.com>,
Mike Snitzer <snitzer@redhat.com>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
"dm-devel@redhat.com" <dm-devel@redhat.com>,
Alasdair G Kergon <agk@redhat.com>, Joe Thornber <ejt@redhat.com>,
Mikulas Patocka <mpatocka@redhat.com>,
Vivek Goyal <vgoyal@redhat.com>,
Sami Tolvanen <samitolvanen@google.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
Heinz Mauelshagen <heinzm@redhat.com>,
linux-mm <linux-mm@kvack.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
Date: Mon, 7 Sep 2015 11:30:26 +0200 [thread overview]
Message-ID: <20150907113026.5bb28ca3@redhat.com> (raw)
In-Reply-To: <CA+55aFzBTL=DnC4zv6yxjk0HxwxWpOhpKDPA8zkTGdgbh08sEg@mail.gmail.com>
On Thu, 3 Sep 2015 20:51:09 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Thu, Sep 3, 2015 at 8:26 PM, Dave Chinner <dchinner@redhat.com> wrote:
> >
> > The double standard is the problem here. No notification, proof,
> > discussion or review was needed to turn on slab merging for
> > everyone, but you're setting a very high bar to jump if anyone wants
> > to turn it off in their code.
>
> Ehh. You realize that almost the only load that is actually seriously
> allocator-limited is networking?
>
> And slub was beating slab on that? And slub has been doing the merging
> since day one. Slab was just changed to try to keep up with the
> winning strategy.
Sorry, I have to correct you on this. The slub allocator is not as
fast as you might think. The slab allocator is actually faster for
networking.
IP-forwarding, single CPU, single flow UDP (highly tuned):
* Allocator slub: 2043575 pps
* Allocator slab: 2088295 pps
Difference slab faster than slub:
* +44720 pps and -10.48ns
The slub allocator have a faster "fastpath", if your workload is
fast-reusing within the same per-cpu page-slab, but once the workload
increases you hit the slowpath, and then slab catches up. Slub looks
great in micro-benchmarking.
As you can see in patchset:
[PATCH 0/3] Network stack, first user of SLAB/kmem_cache bulk free API.
http://thread.gmane.org/gmane.linux.kernel.mm/137469/focus=376625
I'm working on speeding up slub to the level of slab. And it seems
like I have succeeded with half-a-nanosec 2090522 pps (+2227 pps or
0.51 ns).
And with "slab_nomerge" I get even high performance:
* slub: bulk-free and slab_nomerge: 2121824 pps
* Diff to slub: +78249 and -18.05ns
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
--
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:[~2015-09-07 9:30 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-02 23:13 slab-nomerge (was Re: [git pull] device mapper changes for 4.3) Linus Torvalds
2015-09-03 0:48 ` Andrew Morton
2015-09-03 0:53 ` Mike Snitzer
2015-09-03 0:51 ` Mike Snitzer
2015-09-03 0:51 ` Mike Snitzer
2015-09-03 1:21 ` Linus Torvalds
2015-09-03 2:31 ` Mike Snitzer
2015-09-03 3:10 ` Christoph Lameter
2015-09-03 4:55 ` Andrew Morton
2015-09-03 6:09 ` Pekka Enberg
2015-09-03 8:53 ` Dave Chinner
2015-09-03 3:11 ` Linus Torvalds
2015-09-03 6:02 ` Dave Chinner
2015-09-03 6:13 ` Pekka Enberg
2015-09-03 10:29 ` Jesper Dangaard Brouer
2015-09-03 16:19 ` Christoph Lameter
2015-09-04 9:10 ` Jesper Dangaard Brouer
2015-09-04 14:13 ` Christoph Lameter
2015-09-04 6:35 ` Sergey Senozhatsky
2015-09-04 7:01 ` Linus Torvalds
2015-09-04 7:59 ` Sergey Senozhatsky
2015-09-04 9:56 ` Sergey Senozhatsky
2015-09-04 14:05 ` Christoph Lameter
2015-09-04 14:11 ` Linus Torvalds
2015-09-05 2:09 ` Sergey Senozhatsky
2015-09-05 2:09 ` Sergey Senozhatsky
2015-09-05 20:33 ` Linus Torvalds
2015-09-07 8:44 ` Sergey Senozhatsky
2015-09-08 0:22 ` Sergey Senozhatsky
2015-09-03 15:02 ` Linus Torvalds
2015-09-04 3:26 ` Dave Chinner
2015-09-04 3:51 ` Linus Torvalds
2015-09-05 0:36 ` Dave Chinner
2015-09-05 0:36 ` Dave Chinner
2015-09-07 9:30 ` Jesper Dangaard Brouer [this message]
2015-09-07 20:22 ` Linus Torvalds
2015-09-07 20:22 ` Linus Torvalds
2015-09-07 21:17 ` Jesper Dangaard Brouer
2015-09-04 13:55 ` Christoph Lameter
2015-09-04 22:46 ` Dave Chinner
2015-09-05 0:25 ` Christoph Lameter
2015-09-05 1:16 ` Dave Chinner
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=20150907113026.5bb28ca3@redhat.com \
--to=brouer@redhat.com \
--cc=agk@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=dchinner@redhat.com \
--cc=dm-devel@redhat.com \
--cc=ejt@redhat.com \
--cc=heinzm@redhat.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-mm@kvack.org \
--cc=mpatocka@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=samitolvanen@google.com \
--cc=snitzer@redhat.com \
--cc=torvalds@linux-foundation.org \
--cc=vgoyal@redhat.com \
--cc=viresh.kumar@linaro.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.