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

[Dave Chinner]

On Thu, Sep 03, 2015 at 08:51:09PM -0700, Linus Torvalds wrote:
> On Thu, Sep 3, 2015 at 8:26 PM, Dave Chinner <dchinner at 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?

Of course I do - I've been following Jesper's work quite closely
because we might be able to make use of the batch allocation
mechanism in the XFS inode cache in certain workloads where we are
burning through a million inode slab allocations a second...

But again, you're bringing up justifications for a change that were
not documented in the commit message for the change. It didn't even
mention performance (just fragmentation and memory savings). If this
was such a critical factor in making this decision, then why weren't
such workloads and numbers provided with the commit? And why didn't
someone from netowkring actually review the change and ack/test that
it did actually do what it was supposed to?

If you are going to make an assertion, then you damn well better
provide numbers to go along with that assertion. What's you're
phrase, Linus? "Numbers talk and BS walks?" Where are the numbers,
Linus? Hmmmm?

Indeed, with network slabs that hot, mixing them with random other
slab caches could have a negative effect on performance by
increasing contention on the slab over what the network load already
brings. I learnt that lesson 12 years ago when optimisng the mbuf
slab allocator in the Irix network stack to scale to >1Mpps through
16 GbE cards: It worked just fine until we started doing something
with the data that the network was delivering and created more load
on the shared slab....

But, I digress. I've been trying to explain why we shouldn't be merging
slabs with shrinkers and you've shifted the goal posts rather
than addressing the discussion at hand.

> 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.

The key slab tha I monitor for fragmentation behaviour (the XFS
inode slab) does not get merged. Ever. SLAB or SLUB. Because it has
a *constructor*.  Linus, if you bothered to read my previous
comments in this discussion then you'd know this.  I just want to
flag to extend that behaviour to all the slab caches I actively
manage with shrinkers, because slab merging does not benefit them
the same way it does passive slabs. That's not hard to understand,
nor is it a major issue for anyone.

>From my perspective, Linus, you're way out of line. You are not
engaging on a technical level - you're not even reading the
arguments I've been presenting. You're just cherry-picking something
mostly irrelelvant to the problem being discussed and going off at a
tangent ranting and swearing and trying your best to be abusive.
Your behaviour and bluster does not intimidate me, so please try to
be a bit more civil and polite and engage properly on a technical
level.


-Dave.
-- 
Dave Chinner
dchinner at redhat.com