From: Linus Torvalds <torvalds@linux-foundation.org>
To: Dave Chinner <dchinner@redhat.com>
Cc: 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>
Subject: Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)
Date: Thu, 3 Sep 2015 20:51:09 -0700 [thread overview]
Message-ID: <CA+55aFzBTL=DnC4zv6yxjk0HxwxWpOhpKDPA8zkTGdgbh08sEg@mail.gmail.com> (raw)
In-Reply-To: <20150904032607.GX1933@devil.localdomain>
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.
Really. You seem to think that this merging thing is new. It's really
not. Where did you miss the part that it's been done since 2007?
It's only new for slab, and the reason it was introduced for slab was
that it was losing most relevant benchmarks to slub.
So do you now want a "SLAB_NO_MERGE_IF_NOT_SLUB" flag, which keeps the
traditional behavior for slab and slub? Just because its' traditional?
One that says "if the allocator is slub, then merge, but if the
allocator is slab, then don't merge".
Really, Dave. You have absolutely nothing to back up your points with.
Merging is *not* some kind of "new" thing that was silently enabled
recently to take you by surprise.
That seems to be your *only* argument: that the behavior changed
behind your back. IT IS NOT TRUE. It's only true since you don't seem
to realize that a large portion of the world moved on to SLUB a long
time ago.
Do you seriously believe that a "SLAB_NO_MERGE_IF_NOT_SLUB" flag is a
good idea, just to justify your position of "let's keep the merging
behavior the way it has been"?
Or do you seriously think that it's a good idea to take the
non-merging behavior from the allocator that was falling behind?
So no. The switch to merging behavior was not some kind of "no
discussion" thing. It was very much part of the whole original _point_
of SLUB. And the point of having allocator choices was to see which
one worked best.
SLUB essentially won. We could have just deleted SLAB. I don't think
that would necessarily have been a bad idea. Instead, slab was taught
to try to do some of the same things that worked for slub.
At what point do you just admit that your arguments aren't holding water?
So the fact remains: if you can actually show that not merging is a
good idea for particular slabs, then that's real data. But right now
you are just ignoring the real data and the SLUB we've had over the
years.
And if you continue to spout nonsense about "silent behavioral
changes", the only thing you show is that you don't know what the hell
you are talking about.
So your claim of "double standard" is pure and utter shit. Get over it.
Linus
--
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-04 3:51 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-02 23:13 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 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 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 [this message]
2015-09-05 0:36 ` Dave Chinner
2015-09-07 9:30 ` Jesper Dangaard Brouer
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='CA+55aFzBTL=DnC4zv6yxjk0HxwxWpOhpKDPA8zkTGdgbh08sEg@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--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=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=samitolvanen@google.com \
--cc=snitzer@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox