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

[Linus Torvalds]

On Wed, Sep 2, 2015 at 11:02 PM, Dave Chinner <dchinner at redhat.com> wrote:
> On Wed, Sep 02, 2015 at 06:21:02PM -0700, Linus Torvalds wrote:
>> On Wed, Sep 2, 2015 at 5:51 PM, Mike Snitzer <snitzer at redhat.com> wrote:
>> >
>> > What I made possible with SLAB_NO_MERGE is for each subsystem to decide
>> > if they would prefer to not allow slab merging.
>>
>> .. and why is that a choice that even makes sense at that level?
>>
>> Seriously.
>>
>> THAT is the fundamental issue here.
>
> It makes a lot more sense than you think, Linus.

Not really. Even your argument isn't at all arguing for doing things
at a per-subsystem level - it's an argument about the potential sanity
of marking _individual_ slab caches non-mergable, not an argument for
something clearly insane like "mark all slabs for subsystem X
unmergable".

Can you just admit that that was insane? There is *no* sense in that
kind of behavior.

> Right, it's not xyzzy-specific where 'xyzzy' is a subsystem. The
> flag application is actually *object specific*. That is, the use of
> the individual objects that determines whether it should be merged
> or not.

Yes.

I do agree that something like SLAB_NO_MERGE can make sense on an
actual object-specific level, if you have very specific allocation
pattern knowledge and can show that the merging actually hurts.

But making the subsystem decide that all its slab caches should be
"no-merge" is just BS. You know that. It makes no sense, just admit
it.

> e.g. Slab fragmentation levels are affected more than anything by
> mixing objects with different life times in the same slab.  i.e. if
> we free all the short lived objects from a page but there is one
> long lived object on the page then that page is pinned and we free
> no memory. Do that to enough pages in the slab, and we end up with a
> badly fragmented slab.

The thing is, *if* you can show that kind of behavior for a particular
slab, and have numbers for it, then mark that slab as no-merge, and
document why you did it.

Even then, I'd personally probably prefer to name the bit differently:
rather than talk about an internal implementation detail within slab
("don't merge") it would probably be better to try to frame it in the
semantic different you are looking for (ie in "I want a slab with
private allocation patterns").

But aside from that kind of naming issue, that's very obviously not
what the patch series discussed was doing.

And quite frankly, I don't actually think you have the numbers to show
that theoretical bad behavior.  In contrast, there really *are*
numbers to show the advantages of merging.

So the fragmentation argument has been shown to generally be in favor
of merging, _not_ in favor of that "no-merge" behavior. If you have an
actual real load where that isn't the case, and can show it, then that
would be interesting, but at no point is that "the subsystem just
decided to mark all its slabs no-merge".

               Linus