All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Jackson <pj@sgi.com>
To: Andrew Morton <akpm@osdl.org>
Cc: Simon.Derr@bull.net, linux-kernel@vger.kernel.org,
	nickpiggin@yahoo.com.au, ak@suse.de, haveblue@us.ibm.com,
	mingo@elte.hu, clameter@sgi.com
Subject: Re: [PATCH] Cpuset: alloc_pages_node overrides cpuset constraints
Date: Mon, 20 Mar 2006 00:30:52 -0800	[thread overview]
Message-ID: <20060320003052.7ca3f261.pj@sgi.com> (raw)
In-Reply-To: <20060319230712.5b15ee3e.akpm@osdl.org>

> You're kidding.  This adds more code to every page allocation on every
> machine, cpusets or not.
> 
> I stuck this on top:
> 
>  ...
> 
> But it's a bit ugly.


The code path we care about for this __GFP_NOCPUSET flag is for memory
migration.  When it says it wants memory allocated on a certain node,
it really wants it there.

While I consider it a bug in the cpuset implementation that any kernel
alloc_pages_node(), kmalloc_node() or vmalloc_node() call has the
requested node ignored if it falls outside the current tasks cpuset,
that's not a priority bug in my view.  It's been that way for a year
(since cpusets went in), and no one has noticed.

Christoph - I suspect that the following patch, instead of the one
we sent, would meet with greater approval from Andrew.

The patch below just adds the __GFP_NOCPUSET flag on the memory
migration code path, where we need it.  That code path is not
performance critical.

We can deal with the long standing bug in cpusets, where it overrides
all alloc_pages_node() calls, some other day.

What think you of this, Christoph?  Should we send it to Andrew?


 include/linux/gfp.h |    1 +
 kernel/cpuset.c     |    2 ++
 mm/migrate.c        |    5 +++--
 3 files changed, 6 insertions(+), 2 deletions(-)

--- 2.6.16-rc6-mm2.orig/include/linux/gfp.h	2006-03-18 13:07:51.000000000 -0800
+++ 2.6.16-rc6-mm2/include/linux/gfp.h	2006-03-19 23:55:19.000000000 -0800
@@ -47,6 +47,7 @@ struct vm_area_struct;
 #define __GFP_ZERO	((__force gfp_t)0x8000u)/* Return zeroed page on success */
 #define __GFP_NOMEMALLOC ((__force gfp_t)0x10000u) /* Don't use emergency reserves */
 #define __GFP_HARDWALL   ((__force gfp_t)0x20000u) /* Enforce hardwall cpuset memory allocs */
+#define __GFP_NOCPUSET	((__force gfp_t)0x40000u)/* Ignore cpuset constraints */
 
 #define __GFP_BITS_SHIFT 20	/* Room for 20 __GFP_FOO bits */
 #define __GFP_BITS_MASK ((__force gfp_t)((1 << __GFP_BITS_SHIFT) - 1))
--- 2.6.16-rc6-mm2.orig/kernel/cpuset.c	2006-03-18 13:15:04.000000000 -0800
+++ 2.6.16-rc6-mm2/kernel/cpuset.c	2006-03-19 23:52:42.000000000 -0800
@@ -2209,6 +2209,8 @@ int __cpuset_zone_allowed(struct zone *z
 	node = z->zone_pgdat->node_id;
 	if (node_isset(node, current->mems_allowed))
 		return 1;
+	if (gfp_mask & __GFP_NOCPUSET)
+		return 1;
 	if (gfp_mask & __GFP_HARDWALL)	/* If hardwall request, stop here */
 		return 0;
 
--- 2.6.16-rc6-mm2.orig/mm/migrate.c	2006-03-18 13:12:53.000000000 -0800
+++ 2.6.16-rc6-mm2/mm/migrate.c	2006-03-20 00:24:36.000000000 -0800
@@ -614,12 +614,13 @@ redo:
 			 * a certain old page is moved to so we cannot
 			 * specify the correct address.
 			 */
-			page = alloc_page_vma(GFP_HIGHUSER, vma,
+			page = alloc_page_vma(GFP_HIGHUSER|__GFP_NOCPUSET, vma,
 					offset + vma->vm_start);
 			offset += PAGE_SIZE;
 		}
 		else
-			page = alloc_pages_node(dest, GFP_HIGHUSER, 0);
+			page = alloc_pages_node(dest,
+					GFP_HIGHUSER|__GFP_NOCPUSET, 0);
 
 		if (!page) {
 			err = -ENOMEM;


-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

  reply	other threads:[~2006-03-20  8:31 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-18 20:40 [PATCH] Cpuset: alloc_pages_node overrides cpuset constraints Paul Jackson
2006-03-20  7:07 ` Andrew Morton
2006-03-20  8:30   ` Paul Jackson [this message]
2006-03-20 15:34     ` Christoph Lameter
2006-03-22 16:33 ` Andi Kleen
2006-03-22 18:05   ` Paul Jackson

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=20060320003052.7ca3f261.pj@sgi.com \
    --to=pj@sgi.com \
    --cc=Simon.Derr@bull.net \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=clameter@sgi.com \
    --cc=haveblue@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    /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.