All of lore.kernel.org
 help / color / mirror / Atom feed
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, 08 Nov 2005 15:00:08 +0000	[thread overview]
Message-ID: <20051108150008.GL23749@parisc-linux.org> (raw)
In-Reply-To: <436FF70D.6040604@us.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 4261 bytes --]

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) {

[-- Attachment #2: Type: text/plain, Size: 168 bytes --]

_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

WARNING: multiple messages have this Message-ID (diff)
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) {

  parent reply	other threads:[~2005-11-08 15:00 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-08  0:45 [KJ] [PATCH 0/8] Cleanup slab.c Matthew Dobson
2005-11-08  0:45 ` Matthew Dobson
2005-11-08  0:48 ` [KJ] [PATCH 1/8] Apply CodingStyle to mm/slab.c Matthew Dobson
2005-11-08  0:48   ` Matthew Dobson
2005-11-08  0:50 ` [KJ] [PATCH 2/8] Use 'nid' in slab.c Matthew Dobson
2005-11-08  0:50   ` Matthew Dobson
2005-11-08  7:52   ` [KJ] " Pekka J Enberg
2005-11-08  7:52     ` Pekka J Enberg
2005-11-08  8:48     ` [KJ] " Håkon Løvdal
2005-11-08  0:52 ` [KJ] [PATCH 3/8] Fix alloc_percpu()'s args Matthew Dobson
2005-11-08  0:52   ` Matthew Dobson
2005-11-08  0:53 ` [KJ] [PATCH 4/8] Cleanup kmem_cache_create() Matthew Dobson
2005-11-08  0:53   ` Matthew Dobson
2005-11-08  2:14   ` [KJ] " Roland Dreier
2005-11-08  2:14     ` Roland Dreier
2005-11-08  7:34     ` [KJ] " Pekka J Enberg
2005-11-08  7:34       ` Pekka J Enberg
2005-11-08 18:49       ` [KJ] " Matthew Dobson
2005-11-08 18:49         ` Matthew Dobson
2005-11-08 18:52     ` [KJ] " Christoph Lameter
2005-11-08 18:52       ` Christoph Lameter
2005-11-08 19:04       ` [KJ] " Matthew Dobson
2005-11-08 19:04         ` Matthew Dobson
2005-11-08 19:09         ` [KJ] " Christoph Lameter
2005-11-08 19:09           ` Christoph Lameter
2005-11-08 19:21           ` [KJ] " Matthew Dobson
2005-11-08 19:21             ` Matthew Dobson
2005-11-08 19:59             ` [KJ] " Manfred Spraul
2005-11-08 19:59               ` Manfred Spraul
2005-11-08  7:51   ` [KJ] " Pekka J Enberg
2005-11-08  7:51     ` Pekka J Enberg
2005-11-08 18:54     ` [KJ] " Matthew Dobson
2005-11-08 18:54       ` Matthew Dobson
2005-11-08 15:00   ` Matthew Wilcox [this message]
2005-11-08 15:00     ` [KJ] " Matthew Wilcox
2005-11-08 15:11     ` Pekka J Enberg
2005-11-08 15:11       ` Pekka J Enberg
2005-11-08 19:10       ` Matthew Dobson
2005-11-08 19:10         ` Matthew Dobson
2005-11-08  0:55 ` [KJ] [PATCH 5/8] Cleanup cache_reap() Matthew Dobson
2005-11-08  0:55   ` Matthew Dobson
2005-11-08  0:57 ` [KJ] [PATCH 6/8] Cleanup slabinfo_write() Matthew Dobson
2005-11-08  0:57   ` Matthew Dobson
2005-11-08 10:50   ` [KJ] " Alexey Dobriyan
2005-11-08 10:50     ` Alexey Dobriyan
2005-11-08 18:56     ` Christoph Lameter
2005-11-08 18:56       ` Christoph Lameter
2005-11-08 19:09       ` Matthew Dobson
2005-11-08 19:09         ` Matthew Dobson
2005-11-08  0:58 ` [KJ] [PATCH 7/8] Cleanup set_slab_attr() Matthew Dobson
2005-11-08  0:58   ` Matthew Dobson
2005-11-08  9:43   ` [KJ] " walter harms
2005-11-08 18:59   ` Matthew Dobson
2005-11-08  1:00 ` [KJ] [PATCH 8/8] Inline 3 functions Matthew Dobson
2005-11-08  1:00   ` Matthew Dobson
2005-11-08  7:39   ` [KJ] " Pekka J Enberg
2005-11-08  7:39     ` Pekka J Enberg
2005-11-08 18:59     ` [KJ] " Christoph Lameter
2005-11-08 18:59       ` Christoph Lameter
2005-11-08 19:08     ` [KJ] " Matthew Dobson
2005-11-08 19:08       ` Matthew Dobson
2005-11-10 10:42       ` [KJ] " Adrian Bunk
2005-11-10 10:42         ` Adrian Bunk
2005-11-10 17:04         ` [KJ] " Matthew Dobson
2005-11-10 17:04           ` Matthew Dobson
2005-11-10 17:38           ` [KJ] " Adrian Bunk
2005-11-10 17:38             ` Adrian Bunk
2005-11-10 18:04             ` [KJ] " Oliver Neukum
2005-11-10 18:04               ` Oliver Neukum
2005-11-10 18:20               ` [KJ] " Adrian Bunk
2005-11-10 18:20                 ` Adrian Bunk
2005-11-10 19:22                 ` [KJ] " Oliver Neukum
2005-11-10 19:22                   ` Oliver Neukum
2005-11-10 20:43                   ` [KJ] " Adrian Bunk
2005-11-10 20:43                     ` Adrian Bunk
2005-11-08  7:58 ` [KJ] Re: [PATCH 0/8] Cleanup slab.c Pekka J Enberg
2005-11-08  7:58   ` Pekka J Enberg
2005-11-08 18:56   ` [KJ] " Matthew Dobson
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 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.