From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Christoph Lameter <clameter@sgi.com>
Cc: Matt Mackall <mpm@selenic.com>,
akpm@linux-foundation.org, David Miller <davem@davemloft.net>,
linux-kernel@vger.kernel.org
Subject: Re: + fix-spellings-of-slab-allocator-section-in-init-kconfig.patch added to -mm tree
Date: Wed, 09 May 2007 12:43:11 +1000 [thread overview]
Message-ID: <4641353F.2000408@yahoo.com.au> (raw)
In-Reply-To: <Pine.LNX.4.64.0705081920250.17931@schroedinger.engr.sgi.com>
Christoph Lameter wrote:
> On Tue, 8 May 2007, Matt Mackall wrote:
>
>
>>>>Yes. It can in fact put 512 8-byte objects in a 4k page. More
>>>
>>>So can SLUB.
>>
>>Not without at least a bit per-object of overhead. So you can either
>>fit 512 objects in 4160 bytes or 504 objects in 4k.
>
>
> Slub uses a linked list pointer in the page struct which is NULL if all
> objects are allocated. There is no bit per object overhead.
>
>
>>For the kmalloc case, we do have an 8-byte header, which works out to
>>be about 1/8th of the slop that mainline kmalloc over SLAB has on
>
>
> Exactly. That overhead does not exist in SLUB. Thus SLOB is less efficient
> than SLUB.
What you trade for that is that one page page can only serve one slab.
For small systems, I would not be surprised if that was less space
efficient, even just looking at kmalloc caches in isolation. Or do you
have numbers to support your conclusion?
--
SUSE Labs, Novell Inc.
next prev parent reply other threads:[~2007-05-09 2:43 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-08 23:02 + fix-spellings-of-slab-allocator-section-in-init-kconfig.patch added to -mm tree akpm
2007-05-09 0:23 ` Matt Mackall
2007-05-09 0:32 ` Alan Cox
2007-05-09 0:33 ` Matt Mackall
2007-05-09 0:43 ` Christoph Lameter
2007-05-09 0:51 ` Christoph Lameter
2007-05-09 1:27 ` Matt Mackall
2007-05-09 1:32 ` Christoph Lameter
2007-05-09 1:51 ` David Miller
2007-05-09 1:53 ` Christoph Lameter
2007-05-09 1:55 ` David Miller
2007-05-09 1:57 ` Christoph Lameter
2007-05-09 2:06 ` David Miller
2007-05-09 2:10 ` Nick Piggin
2007-05-09 2:20 ` Christoph Lameter
2007-05-09 2:02 ` Nick Piggin
2007-05-09 2:56 ` Matt Mackall
2007-05-09 3:18 ` Nick Piggin
2007-05-09 3:27 ` Christoph Lameter
2007-05-09 3:47 ` Nick Piggin
2007-05-10 0:42 ` Andrew Morton
2007-05-10 1:00 ` Nick Piggin
2007-05-10 2:27 ` Matt Mackall
2007-05-10 7:15 ` [patch] slob: implement RCU freeing Nick Piggin
2007-05-10 7:19 ` Nick Piggin
2007-05-10 8:22 ` Peter Zijlstra
2007-05-10 8:26 ` Nick Piggin
2007-05-10 8:29 ` Peter Zijlstra
2007-05-09 2:19 ` + fix-spellings-of-slab-allocator-section-in-init-kconfig.patch added to -mm tree Matt Mackall
2007-05-09 2:24 ` Christoph Lameter
2007-05-09 2:43 ` Nick Piggin [this message]
2007-05-09 2:57 ` Christoph Lameter
2007-05-09 3:04 ` Nick Piggin
2007-05-09 3:08 ` Christoph Lameter
2007-05-09 3:25 ` Matt Mackall
2007-05-09 3:16 ` Matt Mackall
2007-05-09 3:24 ` Christoph Lameter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4641353F.2000408@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mpm@selenic.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.