Date: Mon, 3 Oct 2005 19:02:08 +0900
From: Magnus Damm <magnus.damm@xxxxxxxxx>
To: David Lang <david.lang@xxxxxxxxxxxxxxxxxx>
Cc: Dave Hansen <haveblue@xxxxxxxxxx>, Magnus Damm <magnus@xxxxxxxxxxxxx>,
Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>
Subject: Re: [PATCH 00/07][RFC] i386: NUMA emulation
On 10/3/05, David Lang <david.lang@xxxxxxxxxxxxxxxxxx> wrote:On Mon, 3 Oct 2005, Magnus Damm wrote:
On 10/1/05, Dave Hansen <haveblue@xxxxxxxxxx> wrote:On Fri, 2005-09-30 at 16:33 +0900, Magnus Damm wrote:These patches implement NUMA memory node emulation for regular i386 PC:s.
NUMA emulation could be used to provide coarse-grained memory resource control
using CPUSETS. Another use is as a test environment for NUMA memory code or
CPUSETS using an i386 emulator such as QEMU.
This patch set basically allows the "NUMA depends on SMP" dependency to
be removed. I'm not sure this is the right approach. There will likely
never be a real-world NUMA system without SMP. So, this set would seem
to include some increased (#ifdef) complexity for supporting SMP && !
NUMA, which will likely never happen in the real world.
Yes, this patch set removes "NUMA depends on SMP". It also adds some
simple NUMA emulation code too, but I am sure you are aware of that!
I agree that it is very unlikely to find a single-processor NUMA
system in the real world. So yes, "[PATCH 02/07] i386: numa on
non-smp" adds _some_ extra complexity. But because SMP is set when
supporting more than one cpu, and NUMA is set when supporting more
than one memory node, I see no reason why they should be dependent on
each other. Except that they depend on each other today and breaking
them loose will increase complexity a bit.
hmm, observation from the peanut gallery, would it make sene to look at
useing the NUMA code on single proc machines that use PAE to access more
then 4G or ram on a 32 bit system?
Hm, maybe? =) What would you like to accomplish by that?