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

["Ted Ts'o" <tytso@mit.edu>]

On Wed, Sep 15, 2010 at 01:33:07PM -0700, David Rientjes wrote:
> 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.

I agree, it would be cleaner if we could separate out the data
structures which are used for accounting for the number of objects
allocated and reclaimed for each object type, and then have a separate
data structure which is used for dealing with the pages used by those
slabs that have been merged together.

All I can say is I hope the merging code is intelligent.  We recently
had a problem where we were wasting huge amounts of memory because we
were allocating large numbers of a the ext4_group_info structure,
which was 132 bytes, and for which kmalloc() used a size-256 slab ---
and the wasted memory was enough to cause OOM's in a critical
(unfortunately statically sized) container when the disks got large
enough and numerous enough.  The fix was to use a separate cache just
for these 132-byte objects, and not to use kmalloc().

I would be really annoyed if we switched to a slab allocator which did
merging, and then found that the said slab allocator helpfully merged
the 132-byte slab cache and the size-256 slab into a single slab
cache, on the grounds that it thought it would save memory...  (I
guess I'm just really really nervous about merging happening behind my
back, and I really like having the per-object type allocation
statistics.)

							- Ted