All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
To: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Dhaval Giani <dhaval@linux.vnet.ibm.com>,
	clameter@sgi.com, bob.picco@hp.com, nacc@us.ibm.com,
	kamezawa.hiroyu@jp.fujitsu.com, mel@skynet.ie,
	akpm@linux-foundation.org, Balbir Singh <balbir@in.ibm.com>,
	Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>,
	lkml <linux-kernel@vger.kernel.org>,
	ckrm-tech <ckrm-tech@lists.sourceforge.net>
Subject: Re: Regression in 2.6.23-rc2-mm2, mounting cpusets causes a hang
Date: Tue, 14 Aug 2007 17:37:12 -0400	[thread overview]
Message-ID: <1187127432.6281.135.camel@localhost> (raw)
In-Reply-To: <20070814204951.GA2065@vino.hallyn.com>

On Tue, 2007-08-14 at 15:49 -0500, Serge E. Hallyn wrote:
<snip>
> 
> Here is a patch which fixes the bug on my system.  As noted in
> the patch description, there are other calls to node_set_state() in
> mm/page_alloc.c which might also need to be switched to node_set(),
> if this is deemed the right solution.

Here's an update to that patch to handle the other 2 places I found
where node_set_state() would be a no-op when MAX_NUMNODES == 1.

I'm continuing to look at uses of node_online_map throughout the kernel.
I'll look at current usage of the node state wrappers as well.  However,
you probably want to fix these other 2 places as well, or you might run
into other issues with empty 'NORMAL_MEMORY and 'CPU node state masks...

Lee

[PATCH 1/1] memoryless: actually set node_states[N_HIGH_MEMORY] - v2

v1 -> v2"
+  switch to node_set() to initialize N_NORMAL_MEMORY and N_CPU
   node_states[] as well.

If CONFIG_NODES_SHIFT is unset, then MAX_NUMNODES=1, and
node_set_state() does nothing.  This means that __build_all_zonelists()
does not actually set node_states[N_HIGH_MEMORY].  cpusets needs
 node_states[N_HIGH_MEMORY] to be correctly set, or it will raise a
bug when a new cpuset is created.

Switch to using node_set() in __build_all_zonelists() to
make sure it is actually set.

Note there are other calls to node_set_state() in mm/page_alloc.c,
which perhaps should also be modified.  Since this area is completely
foreign to me I thought I'd first make sure this is the right approach.

	addressed in v2 --lts

Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
Signed-off-by: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>

 mm/page_alloc.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

Index: Linux/mm/page_alloc.c
===================================================================
--- Linux.orig/mm/page_alloc.c	2007-08-14 16:48:28.000000000 -0400
+++ Linux/mm/page_alloc.c	2007-08-14 16:57:24.000000000 -0400
@@ -2425,7 +2425,8 @@ static void check_for_regular_memory(pg_
 	for (zone_type = 0; zone_type <= ZONE_NORMAL; zone_type++) {
 		struct zone *zone = &pgdat->node_zones[zone_type];
 		if (zone->present_pages)
-			node_set_state(zone_to_nid(zone), N_NORMAL_MEMORY);
+			node_set(zone_to_nid(zone),
+					node_states[N_NORMAL_MEMORY]);
 	}
 #endif
 }
@@ -2443,7 +2444,7 @@ static int __build_all_zonelists(void *d
 
 		/* Any memory on that node */
 		if (pgdat->node_present_pages)
-			node_set_state(nid, N_HIGH_MEMORY);
+			node_set(nid, node_states[N_HIGH_MEMORY]);
 		check_for_regular_memory(pgdat);
 	}
 	return 0;
@@ -2793,7 +2794,7 @@ static int __cpuinit process_zones(int c
 			 	(zone->present_pages / percpu_pagelist_fraction));
 	}
 
-	node_set_state(node, N_CPU);
+	node_set(node, node_states[N_CPU]);
 	return 0;
 bad:
 	for_each_zone(dzone) {



  parent reply	other threads:[~2007-08-14 21:56 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-12 15:21 Regression in 2.6.23-rc2-mm2, mounting cpusets causes a hang Dhaval Giani
2007-08-13 20:12 ` Serge E. Hallyn
2007-08-14 15:03   ` Lee Schermerhorn
2007-08-14 18:03     ` Serge E. Hallyn
2007-08-14 18:13       ` Lee Schermerhorn
2007-08-14 19:23         ` Serge E. Hallyn
2007-08-14 20:49           ` Serge E. Hallyn
2007-08-14 21:07             ` Lee Schermerhorn
2007-08-14 21:28             ` Christoph Lameter
2007-08-14 21:41               ` Lee Schermerhorn
2007-08-14 21:56                 ` Christoph Lameter
2007-08-15 13:43                   ` Lee Schermerhorn
2007-08-15 14:31                     ` Serge E. Hallyn
2007-08-15 16:23                       ` Lee Schermerhorn
2007-08-15 16:31                         ` Serge E. Hallyn
2007-08-15 16:52                           ` Dhaval Giani
2007-08-15 17:08                             ` Serge E. Hallyn
2007-08-15 18:07                             ` Lee Schermerhorn
2007-08-15 20:39                               ` Christoph Lameter
2007-08-16 13:26                             ` Lee Schermerhorn
2007-08-16 19:14                               ` Christoph Lameter
2007-08-15 20:38                           ` Christoph Lameter
2007-08-15 16:31                       ` Paul Jackson
2007-08-15 16:29                     ` Paul Jackson
2007-08-15 17:12                       ` Serge E. Hallyn
2007-08-15 18:00                         ` Lee Schermerhorn
2007-08-15 18:33                           ` Andrew Morton
2007-08-31 16:54                             ` [ckrm-tech] " Paul Menage
2007-08-16  4:46                       ` Paul Menage
2007-08-15 20:36                     ` Christoph Lameter
2007-08-15 20:48                       ` Lee Schermerhorn
2007-08-16  2:36                         ` [ckrm-tech] " Paul Jackson
2007-08-14 21:37             ` Lee Schermerhorn [this message]
2007-08-14 21:39               ` Christoph Lameter
2007-08-14 21:01           ` Lee Schermerhorn

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=1187127432.6281.135.camel@localhost \
    --to=lee.schermerhorn@hp.com \
    --cc=akpm@linux-foundation.org \
    --cc=balbir@in.ibm.com \
    --cc=bob.picco@hp.com \
    --cc=ckrm-tech@lists.sourceforge.net \
    --cc=clameter@sgi.com \
    --cc=dhaval@linux.vnet.ibm.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mel@skynet.ie \
    --cc=nacc@us.ibm.com \
    --cc=serge@hallyn.com \
    --cc=vatsa@linux.vnet.ibm.com \
    /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.