[lkml]   [2001]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] Scheduler issue 1, RT tasks ...
    On Thu, 20 Dec 2001, george anzinger wrote:

    > Davide Libenzi wrote:
    > >
    > > I'd like to have some comments about RT tasks implementation in a SMP
    > > system because POSIX it's not clear about how the priority rules apply to
    > > multiprocessor systems.
    > > The Balanced Multi Queue Scheduler ( BMQS, )
    > > i'm working on tries to keep CPU schedulers the more independent as
    > > possible and currently implements two kind of RT tasks, local one and
    > > global ones.
    > > Local RT tasks apply POSIX priority rules inside the local CPU, that means
    > > that an RT task running on CPU0 cannot preempt another task ( being it
    > > normal or RT ) on CPU1. This keeps schedulers interlocking very low
    > > because of the very fast path in reschedule_idle() ( no multi lock
    > > acquisition, CPU queue loops, etc...).
    > > Global RT tasks, that live in a separate run queue, have the ability to
    > > preempt remote CPU and this can lead ( in the unfortunate case that the
    > > last CPU running the RT task is running another RT task ) to an higher
    > > cost in reschedule_idle().
    > > The check for a global RT task selection is done in a very fast way before
    > > checking the local queue :
    > >
    > > if (!list_empty(&runqueue_head(RT_QID)))
    > > goto rt_queue_select;
    > > rt_queue_select_back:
    > >
    > > and this does not affect the scheduler latency at all.
    > > On the contrary, by having a separate queue for global RT tasks, can
    > > improve it in high run queue load cases.
    > > The local/global RT task selection is done with setscheduler() with a new
    > > ( or'ed ) flag SCHED_RTGLOBAL, and this means that the default is RT task
    > > local.
    > > I'd like to have comments on this before jumping to the next Scheduler
    > > issue ( balancing mode ).
    > >
    > My understanding of the POSIX standard is the the highest priority
    > task(s) are to get the cpu(s) using the standard calls. If you want to
    > deviate from this I think the standard allows extensions, but they IMHO
    > should be requested, not the default, so I would turn your flag around
    > to force LOCAL, not GLOBAL.

    So, you're basically saying that for a better standard compliancy it's
    better to have global preemption policy by default. And having users to
    request rt tasks localization explicitly. It's fine for me.

    - Davide

    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: 2005-03-22 13:14    [W:0.022 / U:0.448 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site