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

[Dave Chinner]

On Fri, Sep 04, 2015 at 08:55:25AM -0500, Christoph Lameter wrote:
> On Fri, 4 Sep 2015, Dave Chinner wrote:
> 
> > There are generic cases where it hurts, so no justification should
> > be needed for those cases...
> 
> Inodes and dentries have constructors. These slabs are not mergeable and
> will never be because they have cache specific code to be executed on the
> object.

I know - I said as much early on in this discussion. That's one of
the generic cases I'm refering to.

I also said that the fact that they are not merged is really by
chance, not by good management. They are not being merged because of
the constructor, not because they have a shrinker. hell, I even said
that if it comes down to it, we don't even need SLAB_NO_MERGE
because we can create dummy constructors to prevent merging....

> > Really, we don't need some stupidly high bar to jump over here -
> > whether merging should be allowed can easily be answered with a
> > simple question: "Does the slab have a shrinker or does it back a
> > mempool?" If the answer is yes then using SLAB_SHRINKER or
> > SLAB_MEMPOOL to trigger the no-merge case doesn't need any more
> > justification from subsystem maintainers at all.
> 
> The slab shrinkers do not use mergeable slab caches.

Please, go back and read what i've already said.

*Some* shrinkers act on mergable slabs because they have no
constructor. e.g. the xfs_dquot and xfs_buf shrinkers.  I want to
keep them separate just like the inode cache is kept separate
because they have workload based demand peaks in the millions of
objects and LRU based shrinker reclaim, just like inode caches do.

That's what I want SLAB_SHRINKER for - to explicitly tell the slab
cache creation that I have a shrinker on this slab and so it should
not merge it with others. Every slab that has a shrinker should be
marked with this flag - we should not be relying on constructors to
prevent merging of critical slab caches with shrinkers....

I really don't see the issue here - explicitly encoding and
documenting the behaviour we've implicitly been relying on for years
is something we do all the time. Code clarity and documented
behaviour is a *good thing*.

Cheers,

Dave.
-- 
Dave Chinner
dchinner at redhat.com