public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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


  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