Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]

Peter Williams
2007-04-17T04:25:47Z

Nick Piggin wrote:
> On Mon, Apr 16, 2007 at 04:10:59PM -0700, Michael K. Edwards wrote:
>> On 4/16/07, Peter Williams <pwil3058@bigpond.net.au> wrote:
>>> Note that I talk of run queues
>>> not CPUs as I think a shift to multiple CPUs per run queue may be a good
>>> idea.
>> This observation of Peter's is the best thing to come out of this
>> whole foofaraw. Looking at what's happening in CPU-land, I think it's
>> going to be necessary, within a couple of years, to replace the whole
>> idea of "CPU scheduling" with "run queue scheduling" across a complex,
>> possibly dynamic mix of CPU-ish resources. Ergo, there's not much
>> point in churning the mainline scheduler through a design that isn't
>> significantly more flexible than any of those now under discussion.
>
> Why? If you do that, then your load balancer just becomes less flexible
> because it is harder to have tasks run on one or the other.
>
> You can have single-runqueue-per-domain behaviour (or close to) just by
> relaxing all restrictions on idle load balancing within that domain. It
> is harder to go the other way and place any per-cpu affinity or
> restirctions with multiple cpus on a single runqueue.

Allowing N (where N can be one or greater) CPUs per run queue actually
increases flexibility as you can still set N to 1 to get the current
behaviour.

One advantage of allowing multiple CPUs per run queue would be at the
smaller end of the system scale i.e. a PC with a single hyper threading
chip (i.e. 2 CPUs) would not need to worry about load balancing at all
if both CPUs used the one runqueue and all the nasty side effects that
come with hyper threading would be minimized at the same time.

Peter
--
Peter Williams pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce