From: Matthew Wilcox <matthew@wil.cx>
To: Matthew Dobson <colpatch@us.ibm.com>
Cc: kernel-janitors@lists.osdl.org,
Pekka J Enberg <penberg@cs.Helsinki.FI>,
linux-kernel@vger.kernel.org
Subject: Re: [KJ] [PATCH 4/8] Cleanup kmem_cache_create()
Date: Tue, 8 Nov 2005 08:00:08 -0700 [thread overview]
Message-ID: <20051108150008.GL23749@parisc-linux.org> (raw)
In-Reply-To: <436FF70D.6040604@us.ibm.com>
On Mon, Nov 07, 2005 at 04:53:33PM -0800, Matthew Dobson wrote:
> @@ -1652,9 +1649,9 @@ kmem_cache_t *kmem_cache_create(const ch
> * gfp() funcs are more friendly towards high-order requests,
> * this should be changed.
> */
> - do {
> - unsigned int break_flag = 0;
> -cal_wastage:
> + unsigned int break_flag = 0;
> +
> + for ( ; ; cachep->gfporder++) {
> cache_estimate(cachep->gfporder, size, align, flags,
> &left_over, &cachep->num);
> if (break_flag)
> @@ -1662,13 +1659,13 @@ cal_wastage:
> if (cachep->gfporder >= MAX_GFP_ORDER)
> break;
> if (!cachep->num)
> - goto next;
> - if (flags & CFLGS_OFF_SLAB &&
> - cachep->num > offslab_limit) {
> + continue;
> + if ((flags & CFLGS_OFF_SLAB) &&
> + (cachep->num > offslab_limit)) {
> /* This num of objs will cause problems. */
> - cachep->gfporder--;
> + cachep->gfporder -= 2;
> break_flag++;
> - goto cal_wastage;
> + continue;
> }
>
> /*
> @@ -1680,33 +1677,29 @@ cal_wastage:
>
> if ((left_over*8) <= (PAGE_SIZE<<cachep->gfporder))
> break; /* Acceptable internal fragmentation. */
> -next:
> - cachep->gfporder++;
> - } while (1);
> + }
> }
I also don't like your changes to this. Might I suggest:
Index: mm/slab.c
===================================================================
RCS file: /var/cvs/linux-2.6/mm/slab.c,v
retrieving revision 1.31
diff -u -p -r1.31 slab.c
--- mm/slab.c 14 Feb 2005 02:55:36 -0000 1.31
+++ mm/slab.c 8 Nov 2005 14:58:35 -0000
@@ -1150,6 +1150,53 @@ static void slab_destroy (kmem_cache_t *
}
}
+/*
+ * Calculate size (in pages) of slabs, and the num of objs per slab. This
+ * could be made much more intelligent. For now, try to avoid using high
+ * page-orders for slabs. When the gfp() funcs are more friendly towards
+ * high-order requests, this should be changed.
+ */
+static size_t find_best_slab_order(kmem_cache_t *cachep, size_t size,
+ size_t align, unsigned long flags)
+{
+ size_t left_over = 0;
+
+ for ( ; ; cachep->gfporder++) {
+ unsigned int num;
+ size_t remainder;
+
+ if (cachep->gfporder > MAX_GFP_ORDER) {
+ cachep->num = 0;
+ break;
+ }
+
+ cache_estimate(cachep->gfporder, size, align, flags,
+ &remainder, &num);
+ if (!num)
+ continue;
+
+ if (flags & CFLGS_OFF_SLAB && num > offslab_limit) {
+ /* This num of objs will cause problems. */
+ break;
+ }
+
+ cachep->num = num;
+ left_over = remainder;
+
+ /*
+ * Large num of objs is good, but v. large slabs are
+ * currently bad for the gfp()s.
+ */
+ if (cachep->gfporder >= slab_break_gfp_order)
+ break;
+
+ if ((left_over*8) <= (PAGE_SIZE<<cachep->gfporder))
+ break; /* Acceptable internal fragmentation. */
+ }
+
+ return left_over;
+}
+
/**
* kmem_cache_create - Create a cache.
* @name: A string which is used in /proc/slabinfo to identify this cache.
@@ -1330,44 +1377,7 @@ kmem_cache_create (const char *name, siz
cache_estimate(cachep->gfporder, size, align, flags,
&left_over, &cachep->num);
} else {
- /*
- * Calculate size (in pages) of slabs, and the num of objs per
- * slab. This could be made much more intelligent. For now,
- * try to avoid using high page-orders for slabs. When the
- * gfp() funcs are more friendly towards high-order requests,
- * this should be changed.
- */
- do {
- unsigned int break_flag = 0;
-cal_wastage:
- cache_estimate(cachep->gfporder, size, align, flags,
- &left_over, &cachep->num);
- if (break_flag)
- break;
- if (cachep->gfporder >= MAX_GFP_ORDER)
- break;
- if (!cachep->num)
- goto next;
- if (flags & CFLGS_OFF_SLAB &&
- cachep->num > offslab_limit) {
- /* This num of objs will cause problems. */
- cachep->gfporder--;
- break_flag++;
- goto cal_wastage;
- }
-
- /*
- * Large num of objs is good, but v. large slabs are
- * currently bad for the gfp()s.
- */
- if (cachep->gfporder >= slab_break_gfp_order)
- break;
-
- if ((left_over*8) <= (PAGE_SIZE<<cachep->gfporder))
- break; /* Acceptable internal fragmentation. */
-next:
- cachep->gfporder++;
- } while (1);
+ left_over = find_best_slab_order(cachep, size, align, flags);
}
if (!cachep->num) {
next prev parent reply other threads:[~2005-11-08 15:00 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-08 0:45 [PATCH 0/8] Cleanup slab.c Matthew Dobson
2005-11-08 0:48 ` [PATCH 1/8] Apply CodingStyle to mm/slab.c Matthew Dobson
2005-11-08 0:50 ` [PATCH 2/8] Use 'nid' in slab.c Matthew Dobson
2005-11-08 7:52 ` Pekka J Enberg
2005-11-08 0:52 ` [PATCH 3/8] Fix alloc_percpu()'s args Matthew Dobson
2005-11-08 0:53 ` [PATCH 4/8] Cleanup kmem_cache_create() Matthew Dobson
2005-11-08 2:14 ` Roland Dreier
2005-11-08 7:34 ` Pekka J Enberg
2005-11-08 18:49 ` Matthew Dobson
2005-11-08 18:52 ` Christoph Lameter
2005-11-08 19:04 ` Matthew Dobson
2005-11-08 19:09 ` Christoph Lameter
2005-11-08 19:21 ` Matthew Dobson
2005-11-08 19:59 ` Manfred Spraul
2005-11-08 7:51 ` Pekka J Enberg
2005-11-08 18:54 ` Matthew Dobson
2005-11-08 15:00 ` Matthew Wilcox [this message]
2005-11-08 15:11 ` [KJ] " Pekka J Enberg
2005-11-08 19:10 ` Matthew Dobson
2005-11-08 0:55 ` [PATCH 5/8] Cleanup cache_reap() Matthew Dobson
2005-11-08 0:57 ` [PATCH 6/8] Cleanup slabinfo_write() Matthew Dobson
2005-11-08 10:50 ` [KJ] " Alexey Dobriyan
2005-11-08 18:56 ` Christoph Lameter
2005-11-08 19:09 ` Matthew Dobson
2005-11-08 0:58 ` [PATCH 7/8] Cleanup set_slab_attr() Matthew Dobson
2005-11-08 1:00 ` [PATCH 8/8] Inline 3 functions Matthew Dobson
2005-11-08 7:39 ` Pekka J Enberg
2005-11-08 18:59 ` Christoph Lameter
2005-11-08 19:08 ` Matthew Dobson
2005-11-10 10:42 ` Adrian Bunk
2005-11-10 17:04 ` Matthew Dobson
2005-11-10 17:38 ` Adrian Bunk
2005-11-10 18:04 ` Oliver Neukum
2005-11-10 18:20 ` Adrian Bunk
2005-11-10 19:22 ` Oliver Neukum
2005-11-10 20:43 ` Adrian Bunk
2005-11-08 7:58 ` [PATCH 0/8] Cleanup slab.c Pekka J Enberg
2005-11-08 18:56 ` Matthew Dobson
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=20051108150008.GL23749@parisc-linux.org \
--to=matthew@wil.cx \
--cc=colpatch@us.ibm.com \
--cc=kernel-janitors@lists.osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=penberg@cs.Helsinki.FI \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome