linux-kernel - Re: [Q] Default SLAB allocator

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:	Wed, 17 Oct 2012 17:46:16 -0700
From:	Shentino <shentino@...il.com>
To:	Tim Bird <tim.bird@...sony.com>
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	Ezequiel Garcia <elezegarcia@...il.com>,
	David Rientjes <rientjes@...gle.com>,
	Andi Kleen <andi@...stfloor.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"celinux-dev@...ts.celinuxforum.org" 
	<celinux-dev@...ts.celinuxforum.org>
Subject: Re: [Q] Default SLAB allocator

On Wed, Oct 17, 2012 at 1:33 PM, Tim Bird <tim.bird@...sony.com> wrote:
> On 10/17/2012 12:20 PM, Shentino wrote:
>> Potentially stupid question
>>
>> But is SLAB the one where all objects per cache have a fixed size and
>> thus you don't have any bookkeeping overhead for the actual
>> allocations?
>>
>> I remember something about one of the allocation mechanisms being
>> designed for caches of fixed sized objects to minimize the need for
>> bookkeeping.
>
> I wouldn't say "don't have _any_ bookkeeping", but minimizing the
> bookkeeping is indeed part of the SLAB goals.
>
> However, that is for objects that are allocated at fixed size.
> kmalloc is (currently) a thin wrapper over the slab system,
> and it maps non-power-of-two allocations onto slabs that are
> power-of-two sized.

...yuck?

> So, for example a string that is 18 bytes long
> will be allocated out of a slab with 32-byte objects.  This
> is the wastage that we're talking about here.  "Overhead" may
> have been the wrong word on my part, as that may imply overhead
> in the actual slab mechanisms, rather than just slop in the
> data area.

Data slop (both for alignment as well as for making room for
per-allocation bookkeeping overhead as is often done with userspace
malloc arenas) is precisely what I was referring to here.

Thanks for the answers I was curious.

> As an aside...
>
> Is there a canonical glossary for memory-related terms?  What
> is the correct term for the difference between what is requested
> and what is actually returned by the allocator?  I've been
> calling it alternately "wastage" or "overhead", but maybe there's
> a more official term?
>
> I looked here: http://www.memorymanagement.org/glossary/
> but didn't find exactly what I was looking for.  The closest
> things I found were "internal fragmentation" and
> "padding", but those didn't seem to exactly describe
> the situation here.

Another stupid question.

Is it possible to have both SLAB for fixed sized objects and something
like SLOB or SLUB standing aside with a different pool for variable
sized allocations ala kmalloc?

My hunch is that handling the two cases with separate methods may get
the best of both worlds.  Or layering kmalloc through something that
gets huge blocks from slab and slices them up in ways more amenable to
avoiding power-of-2 slopping.

No memory geek, so my two cents.

>  -- Tim
>
> =============================
> Tim Bird
> Architecture Group Chair, CE Workgroup of the Linux Foundation
> Senior Staff Engineer, Sony Network Entertainment
> =============================
--
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/