All of lore.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 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.