lkml.org 
[lkml]   [2006]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: RT task scheduling
    Date
    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/

    \
     
     \ /
      Last update: 2006-04-06 20:18    [W:7.416 / U:0.116 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site