From: David Lang <david.lang@digitalinsight.com>
To: "Martin J. Bligh" <mbligh@mbligh.org>
Cc: Magnus Damm <magnus.damm@gmail.com>,
Dave Hansen <haveblue@us.ibm.com>,
Magnus Damm <magnus@valinux.co.jp>, linux-mm <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 00/07][RFC] i386: NUMA emulation
Date: Mon, 3 Oct 2005 07:49:41 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.62.0510030748470.11541@qynat.qvtvafvgr.pbz> (raw)
In-Reply-To: <77150000.1128350759@[10.10.2.4]>
In-Reply-To: <77150000.1128350759@[10.10.2.4]>
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
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2005-10-03 14:49 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-30 7:33 Magnus Damm
2005-09-30 7:33 ` [PATCH 01/07] i386: srat non acpi Magnus Damm, Magnus Damm
2005-09-30 7:33 ` [PATCH 02/07] i386: numa on non-smp Magnus Damm, Magnus Damm
2005-09-30 7:33 ` [PATCH 03/07] cpuset: smp or numa Magnus Damm, Magnus Damm
2005-09-30 7:33 ` [PATCH 04/07] i386: numa warning fix Magnus Damm, Isaku Yamahata
2005-09-30 7:33 ` [PATCH 05/07] i386: sparsemem on pc Magnus Damm, Magnus Damm
2005-09-30 15:25 ` Dave Hansen
2005-10-01 0:32 ` Magnus Damm
2005-09-30 7:33 ` [PATCH 06/07] i386: discontigmem " Magnus Damm, Magnus Damm
2005-09-30 7:33 ` [PATCH 07/07] i386: numa emulation " Magnus Damm, Isaku Yamahata
2005-09-30 18:55 ` Dave Hansen
2005-10-03 9:59 ` Magnus Damm
2005-10-03 16:16 ` Dave Hansen
2005-10-04 5:06 ` Magnus Damm
2005-10-04 7:52 ` Hirokazu Takahashi
2005-10-04 9:49 ` Magnus Damm
2005-09-30 15:23 ` [PATCH 00/07][RFC] i386: NUMA emulation Dave Hansen
2005-10-03 2:08 ` Magnus Damm
2005-10-03 7:34 ` David Lang
2005-10-03 10:02 ` Magnus Damm
2005-10-03 13:33 ` David Lang
2005-10-03 14:59 ` Martin J. Bligh
2005-10-03 15:03 ` David Lang
2005-10-03 15:08 ` Martin J. Bligh
2005-10-03 15:13 ` David Lang
2005-10-03 15:25 ` Martin J. Bligh
2005-10-03 15:32 ` David Lang
2005-10-03 15:54 ` Martin J. Bligh
2005-10-03 16:44 ` David Lang
2005-10-03 14:45 ` Martin J. Bligh
2005-10-03 14:49 ` David Lang [this message]
2005-10-03 3:21 ` Paul Jackson
2005-10-03 5:05 ` Magnus Damm
2005-10-03 5:26 ` Hirokazu Takahashi
2005-10-03 5:33 ` Paul Jackson
2005-10-03 5:59 ` Magnus Damm
2005-10-03 7:26 ` Paul Jackson
2005-10-03 5:34 ` Paul Jackson
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=Pine.LNX.4.62.0510030748470.11541@qynat.qvtvafvgr.pbz \
--to=david.lang@digitalinsight.com \
--cc=haveblue@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=magnus.damm@gmail.com \
--cc=magnus@valinux.co.jp \
--cc=mbligh@mbligh.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