LKML Archive on
help / color / mirror / Atom feed
From: "Pekka Enberg" <>
To: "Bin Chen" <>
Subject: Re: kmem_cache_create loop for find the proper gfporder
Date: Sun, 25 Mar 2007 17:30:04 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 3/25/07, Bin Chen <> wrote:
> It is done by increase gfporder for low number to high(possibly 0 to
> MAX_GFP_ORDER). But why increase the gfporder(or slab size) can
> decrease the internal fragmentation?)
> A simple example, suppose the slab management stuff is kept off-slab,
> if the gfporder is zero, and the object size in slab is 1000, the
> wasted space is 4096 mod 1000 = 96, but with 4096 * 2(increase
> gfporder by 1), the space is 8192 mod 1000 = 192, 192 > 96.

You didn't simulate the algorithm long enough. If you had, you'd hit
order five which wastes only 72 bytes in your example.


      reply	other threads:[~2007-03-25 15:30 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-24 23:49 kmem_cache_create loop for find the proper gfporder Bin Chen
2007-03-25 15:30 ` 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).