linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Paul Jackson <pj@sgi.com>
To: Dave Hansen <haveblue@us.ibm.com>
Cc: magnus@valinux.co.jp, linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 00/07][RFC] i386: NUMA emulation
Date: Sun, 2 Oct 2005 20:21:57 -0700	[thread overview]
Message-ID: <20051002202157.7b54253d.pj@sgi.com> (raw)
In-Reply-To: <1128093825.6145.26.camel@localhost>

Dave wrote:
> Also, I worry that simply #ifdef'ing things out like CPUsets' update
> means that CPUsets lacks some kind of abstraction that it should have
> been using in the first place. 

In the abstract, cpusets should just assume that the system has one or
more CPUs, and one or more Memory Nodes.  Ideally, it should not
require either SMP nor NUMA.  Indeed, if you (Magnus) can get it
to compile with just one or the other of those two:

     config CPUSETS
	    bool "Cpuset support"
    -       depends on SMP
    +       depends on SMP || NUMA

then I would hope that it would compile with neither.  The cpuset
hierarchy on such a system would be rather boring, with all cpusets
having the same one CPU and one Memory Node, but it should work ... in
theory of course.

In practice of course, there may be details on the edges that depend on
the current SMP/NUMA limitations, such as:

Magnus wrote:
> Regarding the #ifdef, it
> was added because partition_sched_domain() is only implemented for
> SMP. That symbol has no prototype or implementation when CONFIG_SMP is
> not set. Maybe it is better to add an empty inline function in
> linux/sched.h for !SMP?

An empty inline partition_sched_domain() would be better than ifdef's
in cpuset.c, yes.  Or at least, that's usually the case.  Probably here
too.

In theory at least, I applaud Magnus's work here.  The assymetry of the
SMP/NUMA define structure has always annoyed me slightly, and only been
explainable in my view as a consequence of the historical order of
development.  I had a PC with a second memory board in an ISA slot,
which would qualify as a one CPU, two Memory Node system.

Or what byte us in the future (that PC was a long time ago), the kinks
in the current setup might be a hitch in our side as we extend to
increasingly interesting architectures.

Aside - for those reading this thread on lkml, it originated
on linux-mm.  It looks like Dave added lkml to the cc list.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401

--
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>

  parent reply	other threads:[~2005-10-03  3:21 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
2005-10-03  3:21   ` Paul Jackson [this message]
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=20051002202157.7b54253d.pj@sgi.com \
    --to=pj@sgi.com \
    --cc=haveblue@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=magnus@valinux.co.jp \
    /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