[lkml]   [2006]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: RT task scheduling
Ingo Molnar wrote:
> * Darren Hart <> wrote:
>> My last mail specifically addresses preempt-rt, but I'd like to know
>> people's thoughts regarding this issue in the mainline kernel. Please
>> see my previous post "realtime-preempt scheduling - rt_overload
>> behavior" for a testcase that produces unpredictable scheduling
>> results.
> the rt_overload feature i intend to push upstream-wards too, i just
> didnt separate it out of -rt yet.
> "RT overload scheduling" is a totally orthogonal mechanism to the SMP
> load-balancer (and this includes smpnice too) that is more or less
> equivalent to having a 'global runqueue' for real-time tasks, without
> the SMP overhead associated with that. If there is no "RT overload" [the
> common case even on Linux systems that _do_ make use of RT tasks
> occasionally], the new mechanism is totally inactive and there's no
> overhead. But once there are more RT tasks than CPUs, the scheduler will
> do "global" decisions for what RT tasks to run on which CPU.

Is this good enough? Isn't it possible with the current
try_to_wake_up() implementation (with or without smpnice) for two RT
tasks to end up on the same CPU even when there are less RT tasks than CPUs?

> To put even
> less overhead on the mainstream kernel, i plan to introduce a new
> SCHED_FIFO_GLOBAL scheduling policy to trigger this behavior. [it doesnt
> make much sense to extend SCHED_RR in that direction.]

I wouldn't have thought a new policy was necessary. Why not just do
this for all SCHED_FIFO (or even all RT) tasks?

BTW Does any body in the real world actually use SCHED_RR?

Peter Williams

"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-04-08 02:13    [W:0.152 / U:0.036 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site