Re: slab-nomerge (was Re: [git pull] device mapper changes for 4.3)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Sep 3, 2015 at 8:26 PM, Dave Chinner <dchinner@xxxxxxxxxx> 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@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]