On Mon, 3 Oct 2005, Magnus Damm wrote:
> On 10/1/05, Dave Hansen <[email protected]> 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?
David Lang
On 10/3/05, David Lang <[email protected]> wrote:
> On Mon, 3 Oct 2005, Magnus Damm wrote:
>
> > On 10/1/05, Dave Hansen <[email protected]> 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?
/ magnus
On Mon, 3 Oct 2005, Magnus Damm wrote:
> Date: Mon, 3 Oct 2005 19:02:08 +0900
> From: Magnus Damm <[email protected]>
> To: David Lang <[email protected]>
> Cc: Dave Hansen <[email protected]>, Magnus Damm <[email protected]>,
> linux-mm <[email protected]>,
> Linux Kernel Mailing List <[email protected]>
> Subject: Re: [PATCH 00/07][RFC] i386: NUMA emulation
>
> On 10/3/05, David Lang <[email protected]> wrote:
>> On Mon, 3 Oct 2005, Magnus Damm wrote:
>>
>>> On 10/1/05, Dave Hansen <[email protected]> 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?
if nothing else preferential use of 'local' (non PAE) memory over 'remote'
(PAE) memory for programs, while still useing it all as needed.
this may be done already, but this type of difference between the access
speed of different chunks of ram seems to be exactly the type of thing
that the NUMA code solves the general case for. I'm thinking that it may
end up simplifying things if the same general-purpose logic will work for
the specific case of PAE instead of it being hard coded as a special case.
it also just struck me as the most obvious example of where a UP box could
have a NUMA-like memory arrangement (and therefor a case to justify
decoupling the SMP and NUMA options)
David Lang
> / magnus
>
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
--David Lang <[email protected]> wrote (on Monday, October 03, 2005 00:34:40 -0700):
> On Mon, 3 Oct 2005, Magnus Damm wrote:
>
>> On 10/1/05, Dave Hansen <[email protected]> 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?
2 problems:
1) there aren't any ;-)
2) The memory is not physically differently separated from the CPUs, so
it's not NUMA.
M.
On Mon, 3 Oct 2005, Martin J. Bligh wrote:
>>> 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?
>
> 2 problems:
>
> 1) there aren't any ;-)
> 2) The memory is not physically differently separated from the CPUs, so
> it's not NUMA.
even though it's not physically differently seperated from the CPU(s)
doesn't it's differing performance amount to the same thing?
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
> if nothing else preferential use of 'local' (non PAE) memory over
> 'remote' (PAE) memory for programs, while still useing it all as needed.
Why would you want to do that? ;-)
> this may be done already, but this type of difference between the access
> speed of different chunks of ram seems to be exactly the type of thing
> that the NUMA code solves the general case for.
It is!
> I'm thinking that it
> may end up simplifying things if the same general-purpose logic will
> work for the specific case of PAE instead of it being hard coded as
> a special case.
But that's not the same at all! ;-) PAE memory is the same speed as
the other stuff. You just have a 3rd level of pagetables for everything.
One could (correctly) argue it made *all* memory slower, but it does so
in a uniform fashion.
M.