From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
Dhaval Giani <dhaval@linux.vnet.ibm.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: Wed, 15 Aug 2007 16:48:13 -0400 [thread overview]
Message-ID: <1187210893.5422.60.camel@localhost> (raw)
In-Reply-To: <Pine.LNX.4.64.0708151333230.7628@schroedinger.engr.sgi.com>
On Wed, 2007-08-15 at 13:36 -0700, Christoph Lameter wrote:
> On Wed, 15 Aug 2007, Lee Schermerhorn wrote:
>
> > > So its always true for node 0. The "bit" is set.
> >
> > The issue is with the N_*_MEMORY masks. They don't get initialized
> > properly because node_set_state() is a no-op if !NUMA. So, where we
> > look for intersections with or where we AND with the N_*_MEMORY masks we
> > get the empty set.
>
> That is intentional. Memory is always present if you are on !NUMA. You can
> simply use a default nodemask where only node 0 is set. That is what the
> fallback provides. Maybe it does not provide the right thing for cpusets?
>
> > > We are trying to get cpusets to work with !NUMA?
> >
> > Well, yes. In Serge's case, he's trying to use cpusets with !NUMA.
> > He'll have to comment on the reasons for that. Looking at all of the
> > #ifdefs and init/Kconfig, CPUSET does not depend on NUMA--only SMP and
> > CONTAINERS [altho' methinks CPUSET should select CONTAINERS rather than
> > depend on it...]. So, you can use cpusets to partition of cpus in
> > non-NUMA configs.
>
> Looks like we need to fix cpuset nodemasks for the !NUMA case then?
> It cannot expect to find valid nodemasks if !NUMA.
Well, OK. But Paul really hates #ifdefs in kernel/cpusets.c. He's
asked me to remove them before, so I avoided them here. Cpusets really
should use only nodes with memory--i.e., the N_HIGH_MEMORY state.
>
> > In the more general case, tho', I'm looking at all uses of the
> > node_online_map and for_each_online_node, for instances where they
> > should be replaced with one of the *_MEMORY masks. IMO, generic code
> > that is compiled independent of any CONFIG option, like NUMA, should
> > just work, independent of the config. Currently, as Serge has shown,
>
> AFAIK this works except for cpusets.
So far. I'm replacing other usage of node_online_map with the
N_HIGH_MEMORY mask, as we discussed. I should have that patch ready to
post tomorrow.
>
> > this is not the case. So, I think we should fix the *_MEMORY maps to be
> > correctly populated in both the NUMA and !NUMA cases. A couple of
> > options:
>
> There is no point in having a variable if you know the results because of
> !NUMA. That is the way nodemask.h has always operated.
But, the mask--the N_HIGH_MEMORY array element, that is--is there for
both NUMA and !NUMA [== N_NORMAL_MEMORY for !CONFIG_HIGHMEM]. We just
don't initialize it for the !NUMA case, currently.
>
> > Thoughts?
>
> Lets get either rid of the definitions for the nodemasks in the !NUMA
> case or fix their contents to have the right constant value expected in
> cpusets.
That's what the patch I posted today [option 2] does--statically
initializes the N_*_MEMORY and N_CPU masks to indicate that node 0
exists. Serge and Dhaval have tested it on their platform and it solves
the cpuset mount problem.
Lee
next prev parent reply other threads:[~2007-08-15 20:49 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 [this message]
2007-08-16 2:36 ` [ckrm-tech] " Paul Jackson
2007-08-14 21:37 ` Lee Schermerhorn
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=1187210893.5422.60.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox