LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Martin J. Bligh" <mbligh@mbligh.org>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>, Andi Kleen <ak@suse.de>,
	Christoph Lameter <clameter@sgi.com>,
	bob.picco@hp.com
Subject: Re: [RFC] [PATCH] more support for memory-less-node.
Date: Tue, 13 Feb 2007 09:09:05 -0800	[thread overview]
Message-ID: <45D1F0B1.3020508@mbligh.org> (raw)
In-Reply-To: <20070213155736.1131d46a.kamezawa.hiroyu@jp.fujitsu.com>

KAMEZAWA Hiroyuki wrote:
> In my last posintg, mempolicy-fix-for-memory-less-node patch, there was a 
> discussion 'what do you consider definition of "node" as...?
> I found there is no consensus. But I want to go ahead.
> Before posing patch again, I'd like to discuss more.
> 
> -Kame
> 
> In my understanding, a "node" is a block of cpu, memory, devices.
> and there could be cpu-only-node, memory-only-node, device-only-node...
> 
> There will be discussion. IMHO, to represent hardware configuration
> as it is, this definition is very natural and flexible.
> (And because my work is memory-hotplug, this definition fits me.)
> 
> "Don't support such crazy configuraton" is one of opinions.
> I hear x86_64 doesn't support it and defines node as a block of memory,
> It remaps cpus on memory-less-nodes to other nodes.
> I know ia64 allows memory-less-node. (I don't know about ppc.)
> It works well on my box (and HP's box).

It doesn't make much sense for an architecture independent structure to
be "defined" in different ways by specific architectures. "not
supported" or "currently broken" might be a better description.

Your description of the node is correct, it's an arbitrary container of
one or more resources. Not only is this definition flexible, it's also
very useful, for memory hotplug, odd types of NUMA boxes, etc.

M.

  parent reply	other threads:[~2007-02-13 17:10 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-13  6:57 KAMEZAWA Hiroyuki
2007-02-13  8:29 ` Andi Kleen
2007-02-13  8:38   ` KAMEZAWA Hiroyuki
2007-02-13 17:25     ` Christoph Lameter
2007-02-14  0:12       ` KAMEZAWA Hiroyuki
2007-02-13 17:24   ` Christoph Lameter
2007-02-13 17:09 ` Martin J. Bligh [this message]
2007-02-13 17:45   ` Andi Kleen
2007-02-13 18:03     ` Christoph Lameter
2007-02-13 18:16       ` Martin J. Bligh
2007-02-13 18:50         ` Christoph Lameter
2007-02-14  0:20           ` KAMEZAWA Hiroyuki
2007-02-13 18:11     ` Martin J. Bligh
2007-02-13 18:18       ` Andi Kleen
2007-02-13 18:26         ` Martin J. Bligh
2007-02-13 18:51         ` Bob Picco
     [not found] <7NZO0-6et-1@gated-at.bofh.it>
     [not found] ` <7Oa6N-5If-3@gated-at.bofh.it>
     [not found]   ` <7Oaq4-6ow-7@gated-at.bofh.it>
     [not found]     ` <7Oaq6-6ow-17@gated-at.bofh.it>
2007-02-15 12:21       ` Bodo Eggert

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=45D1F0B1.3020508@mbligh.org \
    --to=mbligh@mbligh.org \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=bob.picco@hp.com \
    --cc=clameter@sgi.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: [RFC] [PATCH] more support for 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).