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

[Christoph Lameter <cl@linux.com>]

On Wed, 2 Sep 2015, Mike Snitzer wrote:

> You're also coming at this from a position that shared slabs are
> automatically good because they have been around for years.
>
> For those years I've not had a need to debug a leak in code I maintain;
> so I didn't notice slabs were merged.  I also haven't observed slab
> corruption being the cause of crashes in DM, block or SCSI.

Hmmm... Thats unusual. I have seen numerous leaks and corruptions that
were debugged using the additional debug code in the slab allocators.
Merging and debugging can be switched on at runtime if necessary and then
you will have a clear separation to be able to track down the offending
code as well as detailed problem reports that help to figure out what was
wrong. It is then typically even possible to fix these bugs without
getting the subsystem specialists involved.

> > Because clearly, that lack of statistics and the possible
> > cross-subsystem corruption hasn't actually been a pressing concern in
> > reality.
>
> Agreed.

To the effect now that even SLAB has adopted cache merging.

> But I'd still like some pointers/help on what makes slab merging so
> beneficial.  I'm sure Christoph and others have justification.  But if
> not then yes the default to slab merging probably should be revisited.

Well, we have discussed the pros and cons for merging a couple of times
but the general consensus was that it is beneficial. Performance on modern
cpu is very sensitive to cache footprint and reducing the overhead of meta
data for object allocation is a worthwhile goal. Also objects are more
likely to be kept cache hot if they can be used by multiple subsystems.
Slab merging also helps with reducing fragmentation since the free
objects on one page can be used for other purposes.

Check out the linux-mm archives for these dissussions.

This has been such an advantage that the feature was ported to SLAB (to
much more signficant effect than SLUB since SLAB is a pig with metadata
per node, per cpu and per kmem_cache). And yes sorry the consequence is
now that you do no longer have a choice. Both slab allocators default to
merging. SLAB had some difficulty staying competitive in performance
without that. Joonsoo Kim made SLAB more competitive last year and one of
the optimizations was to also support merging.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>