Re: [PATCH v2 2/2] SLUB: Mark merged slab caches in /proc/slabinfo

David Rientjes
2010-09-14T20:56:26Z

On Tue, 14 Sep 2010, Linus Torvalds wrote:

> > I can understand how it's confusing that only the first slab cache name is
> > being emitted, and I think that can be changed, but this shows way too
> > much information that is already available when CONFIG_SLUB_DEBUG is used
> > via the sysfs interface.
>
> Umm. Not in any readable form, it isn't.
>

The debug information is available via /proc/slabinfo, the relationships
amongst merged caches is available via /sys/kernel/slab. The former
depends on the latter via Kconfig, so slub requires using both interfaces
because of its implementation of merged caches to understand each cache's
slab usage.

I agree the only way to show this information only via /proc/slabinfo so
that you can ignore the sysfs interface is by doing exactly what is done
here. The problem is that it's an incomplete solution since it's
truncated at 63 chars, it delimits cache names by '+' which is allowed in
names already, and is obfuscated because it doesn't imply caches are
merged (in fact, it implies additional rather than subsumption.

> The cause for this is that I made a bug-report about the wrong slab
> info, with me claiming 400+ thousand entries (taking up 10M of memory)
> for a slub cache that turned out to be entirely innocent.
>
> That's what /proc/slabinfo said, and quite frankly, /proc/slabinfo was
> simply _lying_. It gave very misleading output.
>

I understand, and that's addressed with my suggestion of using the unique
cache identifier for each line in /proc/slabinfo which would map 1:1 to
the sysfs dentries for those merged caches. /proc/slabinfo would then
represent the true slab state by listing actual caches and their usage.

Aggregating 63 chars of cache names on each line of /proc/slabinfo
wouldn't have helped you when it reports 400+ thousand entries because you
still can't identify the guilty cache. For that issue, this would simply
give you a list of suspects, and sysfs is a better inteface for that since
it's complete and not truncated.

> In my not-so-humble opinion, either the merging needs to go away
> entirely, or the misleading output needs to be fixed.

Cache merging may have been advertised as a bigger performance improvement
than it actually is, and I don't do it in my own slab allocator for other
reasons, but it does lead to more effective memory use by reducing slab
fragmentation. On one of my benchmarking servers, over 60% of caches are
merged and /sys/kernel/slab/.../partial reports roughly the same percent
of fewer total partial slabs over the system in comparison to
slub_nomerge.

Indeed, to debug egregious slab usage on your system you would opt-out of
the more efficient memory use by using slub_nomerge and then checking
/proc/slabinfo anyway.