From: "Martin J. Bligh" <mbligh@mbligh.org>
To: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>,
bob.picco@hp.com
Subject: Re: [RFC] [PATCH] more support for memory-less-node.
Date: Tue, 13 Feb 2007 10:16:07 -0800 [thread overview]
Message-ID: <45D20067.2090803@mbligh.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0702130956540.26309@schroedinger.engr.sgi.com>
Christoph Lameter wrote:
> On Tue, 13 Feb 2007, Andi Kleen wrote:
>
>> Adding NULL tests all over mm for this would seem like a clear case
>> of this to me.
>
> Maybe there is an alternative. We are free to number the nodes right?
> How about requiring the low node number to have memory and the high ones
> do not?
>
> F.e. have a boundary like
>
> nr_mem_nodes ?
>
> Everything above nr_mem_nodes has no memory and cannot be specified in a
> nodemask. Those nodes would not be visible to user space via memory
> policies and page migration. So the core mempolicy logic could be left
> untouched.
>
> The nodes above nr_mem_nodes would exist purely within the kernel. They
> would have proximity information (which can be used to determine
> neighboring memory. More flexible then the current attachment
> to one fixed memory node) but those node numbers could not be specified as
> node masks in any memory operations. This would then allow memory less nodes
> with I/O or cpus. The user would not be aware of these.
What's wrong with just setting the existing counters like
node_spanned_pages / node_present_pages to zero?
M.
next prev parent reply other threads:[~2007-02-13 18:17 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-13 6:57 [RFC] [PATCH] more support for memory-less-node 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
2007-02-13 17:45 ` Andi Kleen
2007-02-13 18:03 ` Christoph Lameter
2007-02-13 18:16 ` Martin J. Bligh [this message]
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=45D20067.2090803@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 \
/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