lkml.org 
[lkml]   [2006]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: RT task scheduling
    Date
    On Friday 07 April 2006 20:01, Steven Rostedt wrote:
    > Hi Bill,
    >
    > I'm just catching up on this thread. Is your main concern that a High
    > prio task is going to be unnecessary delayed because there's a lower RT
    > task on the same CPU and time is needed to push it off to another CPU?
    > It's late, so forgive me if this is a stupid question ;)

    What I have gathered from this thread is that there are two important (and
    partially conflicting) requirements for better real-time support.

    1) Deterministic scheduling algorithms (SWSRPS). Basically, with uniprocessor
    systems (or smp with a global run queue), it was really easy to say, run the
    highest priority task in the queue. But when there are several queues that
    are independent of each other, it is difficult. According to SWSRPS, nr_cpus
    highest priority runnable tasks should _always_ be running (regardless of
    which queue they are on). This might mean that there are longer latencies a)
    to determine the nr_cpus highest priority tasks and b) because of cache
    issues.

    2) Maximum deterministic latency. A task should be able to say that if it
    relinquishes the processor for now, MAX_LATENCY nanoseconds (or ticks or
    whatever you want to measure time in) later, it will be back in time to meet
    a deadline.

    As I understand it, real time is all about determinism. But there are several
    places where we have to focus on determinism to make it all behave as it
    should.

    Priority A > B > C
    If a lower priority task C gets run just because it is the highest in that
    CPU's run queue while there is a higher priority task B is sleeping while A
    runs (on a 2 proc system), this is WRONG. But then again, we need to make
    sure that we can determine the maximum latency to preempt C to run B and try
    to minimize that.

    Poof! More smoke in the air. I hope that clears it up.

    --Vernon

    > On Fri, 2006-04-07 at 16:36 -0700, Bill Huey wrote:
    > > > Has this cleared some things up? If not, let me know what else needs
    > > > clarification.
    > >
    > > Yes, but you should really work to clarify terminology. Is this better ?
    >
    > Goes both ways :)
    >
    > -- Steve
    >
    > PS. It's really good to see you back on LKML. I've missed your posts.
    >
    >
    > -
    > 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-08 06:30    [W:0.024 / U:29.804 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site