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

[David Rientjes]

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/