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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100915222509.GE3730@thunk.org>
Date:	Wed, 15 Sep 2010 18:25:09 -0400
From:	Ted Ts'o <tytso@....edu>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Pekka Enberg <penberg@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Christoph Lameter <cl@...ux.com>
Subject: Re: [PATCH v2 2/2] SLUB: Mark merged slab caches in /proc/slabinfo

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