[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0702081129270.11336@schroedinger.engr.sgi.com>
Date: Thu, 8 Feb 2007 11:35:36 -0800 (PST)
From: Christoph Lameter <clameter@....com>
To: Andrew Morton <akpm@...ux-foundation.org>
cc: Andi Kleen <ak@...e.de>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
LKML <linux-kernel@...r.kernel.org>,
GOTO <y-goto@...fujitsu.com>,
Christoph Lameter <clameter@...r.sgi.com>
Subject: Re: [2.6.20][PATCH] fix mempolicy error check on a system with
memory-less-node
On Thu, 8 Feb 2007, Andrew Morton wrote:
> > Surely your computer has some memory so attach it to that memory (which
> > in a NUMA system would be one or the other node).
>
> "attach it". But it _isn't_ attached. There is no memory on this node.
> We seem to be saying that we should misrepresent the physical topology
> because the kernel doesn't handle it appropriately.
I think we are have a disagreement on what node means. Andi is saying that
a node is bound to memory. The affinity of that chunk of memory has to be
considered by the Kernel. If there is no memory then there is no memory
management issue. This memory may have assigned I/O devices and cpus that
use that memory for their operations. I think this is the working
definition of the kernel.
You are saying a node means something that is connected to a NUMA
interlink that may have cpus / memory / IO devices.
It seems that both definitions have been used.
> > Cpu only "nodes" would mean that all memory would be off node. Meaning
> > whatever interconnect one has would be heavily used. Operating system and
> > application performance will suffer.
>
> >From this a logical step would be to change the kernel to refuse to bring
> memoryless nodes online at all.
This is the case.
Arch code typically ignores memory less nodes and assigns processors and
I/O devices with no memory to the next node. F.e. the SGI I/O "node" only
exists on the arch level. They are mapped to the next memory node by
arch coide and the locality information returned to the Kernel for devices
on that I/O node is the next memory node.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists