> If you number each CPU so its two IDs are smp_num_cpus()/2
> apart, you will NOT need to put some crappy hack in the
> scheduler to pack your CPUs correctly.
Which is a major change to the x86 tree and an invasive one. Right now the
X86 is doing a 1:1 mapping, and I can offer Marcelo no proof that somewhere
buried in the x86 arch code there isnt something that assumes this or mixes
a logical and physical cpu id wrongly in error.
At best you are exploiting an obscure quirk of the current scheduler that is
quite likely to break the moment someone factors power management into the
idling equation (turning cpus off and on is more expensive so if you idle
a cpu you want to keep it the idle one for PM). Congratulations on your
zen like mastery of the scheduler algorithm. Now tell me it wont change in
that property.
> > For 2.5 the scheduler needs a rewrite anyway so its a non issue there.
>
> Disagree. Without widespread understanding of how the simple
> scheduler works, writing a more complex one is doomed.
The simple scheduler doesn't work. I've run about 20 schedulers on playing
cards, and at the point you are shuffling things around and its clear what
is happening its actually hard not to start laughing at the current
scheduler once you hit a serious load or serious amounts of processors.
Its a great scheduler for a single or dual processor 486/pentium type box
running a home environment. It gets a bit flaky by the time its running
oracle on a 4 way, it gets very flaky by the time its running lotus back
ends on an 8 way. It doesn't take luancy like java, broken JVM implementations
and volcanomark to make it go astray
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Dec 15 2001 - 21:00:16 EST