Re: Re: OSDL Bug 3770

[Ingo Molnar]

* Loic Domaigne <loic-dev@xxxxxxx> wrote:

> N> lkml: We're discussing the fact that on SMP machines, our realtime 
> N> scheduling policies are per-CPU only. This caused a problem where a 
> N> high priority task on one CPU caused all lower priority tasks on that 
> N> CPU to be starved, while tasks on another CPU with the same low 
> N> priority were able to run.
> 
> That summary should readily motivate you to make a patch ;-)

note that my -RT patchset includes scheduler changes that implement
"global RT scheduling" on SMP systems. Give it a go, it's at:

   http://redhat.com/~mingo/realtime-preempt/

you have to enable CONFIG_PREEMPT_RT to active this feature. I've
designed this code to not hurt non-RT scheduling, and i've optimized
performance for the 'lightly loaded case' (which is the most common to
occur on mainline-using systems).

A very short description of the design: there's a global 'RT overload
counter' - which is zero and causes no overhead if there is at most 1 RT
task in every runqueue.  (i.e. at most 2 RT tasks on a 2-way system, at
most 4 RT tasks on a 4-way system, etc.) If the system gets into 'RT
overload' mode (e.g. the third RT task gets activated on a 2-way box),
then the scheduler starts to balance the RT tasks agressively. Also,
whenever an RT task is preempted on a CPU, or is woken up but cannot
preempt a higher-prio RT task on a given CPU, then it's 'pushed' to
other CPUs if possible. This design avoids global locking (it avoids a
global runqueue), which simplifies things immensely. (I first tried a
global runqueue for RT tasks but the complexity impact was much bigger.)

(note that these scheduler changes are resonably self-contained and do
not depend on other parts of PREEMPT_RT, so in theory they could be
added to mainline too, after some time - given lots of testing and broad
agreement.)

anyway, the first step would be to try this scheduler and give feedback
of how well it works for you :-)

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/