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: <507F160A.7090302@am.sony.com>
Date:	Wed, 17 Oct 2012 13:33:14 -0700
From:	Tim Bird <tim.bird@...sony.com>
To:	Shentino <shentino@...il.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 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.  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.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ