Messages in this thread | | | From | Darren Hart <> | Subject | Re: RT task scheduling | Date | Thu, 6 Apr 2006 11:16:01 -0700 |
| |
On Thursday 06 April 2006 00:37, Ingo Molnar wrote: > * Darren Hart <darren@dvhart.com> 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. 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.] > > my gut feeling is that it would be wrong to integrate this feature into > smpnice: SCHED_FIFO is about determinism, and smpnice is a fundamentally > statistical approach. Also, smpnice doesnt have to try as hard to pick > the right task as rt_overload does, so there would be constant > 'friction' between "overhead" optimizations (dont be over-eager) and > "latency" optimizations (dont be _under_-eager). So i'm quite sure we > want this feature separate. [nevertheless i'd happy to be proven wrong > via some good and working smpnice based solution] > > in any case, i'll check your -rt testcase to see why it fails.
Just as an example, here is the output a failing test case on a 4way machine running 2.6.16-rt13 (a successful run would have a final ball position of 0).
[root@box sched_football]# ./sched_football 4 10 Starting 4 offense threads at priority 15 Starting 4 defense threads at priority 30 Starting referee thread Game On (10 seconds)! Game Over! Final ball position: 5 [root@box sched_football]#
--Darren
> > Ingo > - > 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/ - 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/
| |