From: Pekka Enberg <penberg@cs.helsinki.fi>
To: Olaf Hering <olh@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] record last user if malloc request is exact 4k
Date: Mon, 30 Jan 2006 22:35:25 +0200 [thread overview]
Message-ID: <1138653326.21112.8.camel@localhost> (raw)
In-Reply-To: <20060130202527.GB12315@suse.de>
Hi,
On Mon, Jan 30, Pekka Enberg wrote:
> > For architectures that have 4K pages, adding debugging overhead to 4K
> > objects is pretty much the worst case. Any particular reason you want
> > this?
On Mon, 2006-01-30 at 21:25 +0100, Olaf Hering wrote:
> I'm just curious.
Oh, okay. One or more pages are allocated for each slab depending on
object size. Each slab is then divided into equal-sized buffers which
must fit at one object. A buffer also has optional padding so that
objects respect alignment rules given to a cache. In addition, when
CONFIG_DEBUG_SLAB is enabled, the buffer contains space for red-zone on
left and right of the object and last user information.
When all debugging is enable, the total overhead is padding plus 4 *
sizeof(void *) for red-zoning and one more sizeof(void *) for the last
caller address. If you allow debugging for 4K objects, you have huge
internal fragmentation for both 4 KB and 8 KB pages (almost one full
page). The current 4095 limit isn't perfect either but increasing will
only make things worse. I think it's designed for
<linux/kmalloc_sizes.h> so that the last general object size with
debugging is 2048.
Pekka
prev parent reply other threads:[~2006-01-30 20:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-30 17:49 [PATCH] record last user if malloc request is exact 4k Olaf Hering
2006-01-30 20:23 ` Pekka Enberg
2006-01-30 20:25 ` Olaf Hering
2006-01-30 20:35 ` Pekka Enberg [this message]
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=1138653326.21112.8.camel@localhost \
--to=penberg@cs.helsinki.fi \
--cc=linux-kernel@vger.kernel.org \
--cc=olh@suse.de \
/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.