On 10/3/05, Paul Jackson <[email protected]> wrote:
> 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.
I just tested this on top of my patches:
@@ -245,7 +245,6 @@ config IKCONFIG_PROC
config CPUSETS
bool "Cpuset support"
- depends on SMP || NUMA
help
and it seems to work ok in practice too. On a regular !SMP !NUMA PC
anyway. As you note, the hierarchy is not that exciting. =) Anyway,
both SMP || NUMA or nothing seems to work as dependencies. After
partition_sched_domain() gets fixed that is.
> 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.
I agree.
> 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.
Nice to hear that you like the idea.
Maybe I should have broken down my patches into three smaller sets:
1) i386: NUMA without SMP
2) CPUSETS: NUMA || SMP
3) i386: NUMA emulation
If people like 1) then it's probably a good idea to convert other
architectures too. Both 2) and 3) above are separate but related
issues. And now seems like a good time to solve 2).
So, Paul, please let me know if you prefer SMP || NUMA or no
depencencies in the Kconfig. When I know that I will create a new
patch that hopefully can get into -mm later on.
> Aside - for those reading this thread on lkml, it originated
> on linux-mm. It looks like Dave added lkml to the cc list.
Huh? I sent my patches both to lkml and linux-mm...
Thank you for the feedback!
/ magnus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
