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@xxxxxxxxxx -- 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>