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]

Date:	Thu, 16 Sep 2010 10:49:01 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Christoph Lameter <cl@...ux.com>
Cc:	David Rientjes <rientjes@...gle.com>, "Ted Ts'o" <tytso@....edu>,
	Pekka Enberg <penberg@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] SLUB: Mark merged slab caches in /proc/slabinfo

On Thu, Sep 16, 2010 at 10:39 AM, Christoph Lameter <cl@...ux.com> wrote:
>
> The main point of merging slabs is to reduce memory footprint and
> avoid the overhead of managing more slab caches. Performance is a side
> effect that may come about due to a reduced cache footprint if multiple
> caches that are mapped to the same merged cache are used in the same
> context.

The thing is, if we were to be able to separate the _accounting_ from
the allocation, we'd get the best of both worlds.

Maybe slub could have separate 'struct kmem_cache' structures for each
slab, and not merge at that level, but then have a merged _allocator_.
We already have a level of indirection there due to the whole per-cpu
front-end, so maybe it wouldn't even cause any extra pointer chasing.

That would allow slabtop etc to show the number of actual allocations
at the granularity that we want (ie you'd see who is the real user),
but still then use the same slab pages and avoid the slab
fragmentation.

How painful would it be to try to re-organize things like this?
Impossible? Very hard? Or just "need to think about it a bit"?

                                    Linus
--
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/