All of lore.kernel.org
 help / color / mirror / Atom feed
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


      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.