LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Bob Picco" <bob.picco@hp.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Christoph Lameter <clameter@sgi.com>,
	linux-kernel@vger.kernel.org, y-goto@jp.fujitsu.com,
	clameter@engr.sgi.com, akpm@osdl.org, linux-ia64@vger.kernel.org
Subject: Re: [2.6.20][PATCH] fix mempolicy error check on a system with memory-less-node
Date: Thu, 8 Feb 2007 06:49:01 -0500	[thread overview]
Message-ID: <20070208114901.GA25152@localhost> (raw)
In-Reply-To: <20070207173647.86bd64c0.kamezawa.hiroyu@jp.fujitsu.com>

Hiroyuki KAMEZAWA wrote:	[Wed Feb 07 2007, 03:36:47AM EST]
> On Wed, 7 Feb 2007 00:04:41 -0800 (PST)
> Christoph Lameter <clameter@sgi.com> wrote:
> 
> > On Wed, 7 Feb 2007, KAMEZAWA Hiroyuki wrote:
> > 
> > > > Hmmm... Remove the node from the node_online_map instead?
> > > > 
> > > Changing defintion of node_online_map is harmfil. (there are cpu-only-nodes.)
> > > How about adding  nodemask for nodes equips memory ?
> > 
> > Ok that is better but...
> > 
> > Would it be possible to attach the cpus to the 
> > next nodes with memory and mark the node offline? That way we could avoid 
> > another mask that we constantly have to check?
> > 
> Added ia64 list to CC.
> I know ia64 kernel did what you say in old days (I know RHEL4/2.6.9 kernel does it).
> Someone changed it and created cpu-only-node for some purpose, I don't know why.
That was me. It will probably be later today or Friday before I've had
time to review the code.  For reference look for string memory_less in
arch/ia64/mm/discontig.c.

The short story is HP ships NUMA boxes with interleaved memory only by
default which is represented by a single memory only node. Originally all
the CPU nodes where assigned to the memory node. The code was very
complicated and incorrect to me. Subsequently, and what we have now, the CPU
only nodes are revealed and the memory only node too. I do believe that a
cpu only nodes should be possible but now there seems to be a new issue.

bob
> 
> 
> > Or fix the location where the error occurred to be able to tolerate a node 
> > with no zones?
> > 
> Hmm, 
> In this case, MPOL_MBIND, the user requests to allocate memory from specified nodes.
> I think it's better to tell him "you can't do that" than silently allocating memory
> from other places.
> 
> -Kame
> 
> 
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

  reply	other threads:[~2007-02-08 11:49 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-06 11:23 KAMEZAWA Hiroyuki
2007-02-06 17:26 ` Christoph Lameter
2007-02-07  1:14   ` KAMEZAWA Hiroyuki
2007-02-07  8:04     ` Christoph Lameter
2007-02-07  8:36       ` KAMEZAWA Hiroyuki
2007-02-08 11:49         ` Bob Picco [this message]
2007-02-07 10:20       ` Andi Kleen
2007-02-07 10:20 ` Andi Kleen
2007-02-07 10:07   ` KAMEZAWA Hiroyuki
2007-02-07 10:19     ` Andi Kleen
2007-02-07 10:37       ` KAMEZAWA Hiroyuki
2007-02-07 10:41         ` Andi Kleen
2007-02-07 10:49           ` KAMEZAWA Hiroyuki
2007-02-07 11:32             ` Andi Kleen
2007-02-07 12:27               ` KAMEZAWA Hiroyuki
2007-02-07 14:05     ` Christoph Lameter
2007-02-07 15:28       ` KAMEZAWA Hiroyuki
2007-02-07 14:03   ` Christoph Lameter
2007-02-07 16:23   ` Andrew Morton
2007-02-07 16:50     ` Andi Kleen
2007-02-07 17:43       ` Andrew Morton
2007-02-07 18:15         ` [PATCH] FS : Speedup rw_verify_area() Eric Dumazet
2007-02-08  0:37         ` [2.6.20][PATCH] fix mempolicy error check on a system with memory-less-node KAMEZAWA Hiroyuki
2007-02-08 19:09         ` Christoph Lameter
2007-02-08 19:26           ` Andrew Morton
2007-02-08 19:35             ` Christoph Lameter

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=20070208114901.GA25152@localhost \
    --to=bob.picco@hp.com \
    --cc=akpm@osdl.org \
    --cc=clameter@engr.sgi.com \
    --cc=clameter@sgi.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=y-goto@jp.fujitsu.com \
    --subject='Re: [2.6.20][PATCH] fix mempolicy error check on a system with memory-less-node' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).