linux-kernel - Re: [PATCH] procfs: provide slub's /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: <Pine.LNX.4.64.0801041223250.11479@schroedinger.engr.sgi.com>
Date:	Fri, 4 Jan 2008 12:34:42 -0800 (PST)
From:	Christoph Lameter <clameter@....com>
To:	Matt Mackall <mpm@...enic.com>
cc:	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Hugh Dickins <hugh@...itas.com>,
	Andi Kleen <andi@...stfloor.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] procfs: provide slub's /proc/slabinfo

On Thu, 3 Jan 2008, Matt Mackall wrote:

> > The advantage of SLOB is to be able to put objects of multiple sizes into 
> > the same slab page. That advantage goes away once we have more than a few 
> > objects per slab because SLUB can store object in a denser way than SLOB.
> 
> Ugh, Christoph. Can you please stop repeating this falsehood? I'm sick
> and tired of debunking it. There is no overhead for any objects with
> externally-known size. So unless SLUB actually has negative overhead,
> this just isn't true.

Hmmm.. Seems that I still do not understand how it is possible then to mix 
objects of different sizes in the same slab page. Somehow the allocator 
needs to know the size. So it is not possible in SLOB to use 
kmem_cache_alloc on an object and then free it using kfree?

> > Well if you just have a few dentries then they are likely all pinned. A 
> > large number of dentries will typically result in reclaimable slabs.
> > The slab defrag patchset not only deals with the dcache issue but provides 
> > similar solutions for inode and buffer_heads. Support for other slabs that
> > defragment can be added by providing two hooks per slab.
> 
> What's your point? Slabs have a inherent pinning problem that's ugly to
> combat. SLOB doesn't.

I thought we were talking about pinning problems of dentries. How are 
slabs pinned and why does it matter? If slabs are pineed by a dentry that 
is pinned then the slab page will be filled up with other dentries that 
are not pinned. The slab defrag approach causes a coalescing of objects 
around slabs that have pinned objects.

> SLOB:
> - internal overhead for kmalloc is 2 bytes (or 3 for odd-sized objects)

Well that increase if you need to align the object. For kmalloc this 
usually means cache line align a power of two object right? So we have a 
cacheline size of overhead?

> - internal overhead for kmem_cache_alloc is 0 bytes (or 1 for odd-sized
> objects)

You are not aligning to a double word boundary? This will create issues on 
certain platforms.

> SLAB/SLUB
> - internal overhead for kmalloc averages about 30%

I think that is valid for a random object size distribution?

> - internal overhead for kmem_cache_alloc is (slab-size % object-size) /
> objects-per-slab, which can be quite large for things like SKBs and
> task_structs and is made worse by alignment

Good, so SLOB can fit in small objects in those holes.

The calculation for SLAB is different since it also typically places it 
management structure in the slab. The management structure needs at least 
2 bytes per object.

So the per object overhead in SLAB is

((slab-size - management-structure-overhead) % object-size) / objects-per-slab

> The only time SLAB/SLUB can win in efficiency (assuming they're using
> the same page size) is when all your kmallocs just happen to be powers
> of two. Which, assuming any likely distribution of string or other
> object sizes, isn't often.

In case of SLAB that is true. In case of SLUB we could convert the 
kmallocs to kmem_cache_alloc. The newly created slab would in all 
likelyhood be an alias of an already existing structure and thus be 
essentially free. In that fashion SLUB can (in a limited way) put objects 
for different slab caches into the same slab page too.

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