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

David Rientjes
2010-09-15T20:33:17Z

On Wed, 15 Sep 2010, Theodore Tso wrote:

> > I don't believe that we need to remove cache merging and allocate more
> > memory by default to be able to identify a particular cache using an
> > egregious amount of slab when troubleshooting a problem.
>
> Why not keep a separate accounting for each cache, even if we use the
> same set of pages for a set of slab cache? It is *really* *useful* to
> be able to get that kind of debugging information without needing to
> reboot the system into some kind of magic debugging mode. More than
> once I've had to debug a customer system where there was some kind of
> memory allocation problem, where rebooting wouldn't have been an option,
> or where rebooting would have destroyed the evidence.
>
> It would seem to me that if there was a "super-slab" pointer in the
> slab cache structure, then if it turns out the slab system wants to
> merge a new slab cache with an existing one, you could instead allocate
> a "super slab" structure, copy information from the initial slab cache
> into the "super slab" and then set a pointer to the "super slab". The
> only information that would be kept in the individual slab cache
> structures that have a non-zero "super slab" pointer would be the number
> of objects allocator for that particular object time.
>

I'd love to have per-cache statistics that we could export without the
cost of the extra memory from fragmented partial slabs. You'd have to do
this for every cache even if it's a "superslab", though, to avoid a branch
in the fastpath to find the cpu slab. I'm not sure if Pekka and Christoph
will be happy with the allocation of kmem_cache structures for mergable
caches and the increment of the statistic in the fastpath.