lkml.org 
[lkml]   [1998]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Schedule idle
    On Tue, 10 Nov 1998 yodaiken@chelm.cs.nmt.edu wrote:

    > task, such as the pipe example above. But then we need to do a search on
    > delay chains each time a process blocks too because:
    > LowA | LowB | LowC | RT_Critical
    > means that LowA,LowB, and LowC must all be promoted, thus when RT_Critical
    > first blocks on its pipe, the OS needs to determine the entire chain,

    No, this is not a case of a system lock held or the
    kernel blocking in a critical region (yes, I understand
    this argument is promoting your point of view).

    > and dynamically adjust it as the pipes fill and empty. Now all
    > system tasks pay the price for this "feature" whether they need it
    > or not.
    >
    > Is that really what you want?

    Not really. My plan was to only use the feature for
    specifically marked critical regions inside the
    kernel. An RT task waiting for data from an idler
    process is artificial (and dumb) enough for me not
    to care...

    > > > Still no specification. What is the desired semantics of process
    > > > operation?
    > >
    > > An RT process should run ASAP. I guess we can all agree
    >
    > Good sentiment!
    > How is this different from any other process?

    For other processes we make a tradeoff between throughput
    and latency. When you look at it a bit more in detail,
    you'll see that latency is compromised to the point of
    the system getting unuseable.

    For RT tasks latency is all and throughput is sacrificed
    entirely. The only reason that RT tasks can do something
    useful is because we don't take the CPU away from them...

    > X needs to run ASAP or the screen looks bad, Emacs needs to
    > run ASAP or it does not respond to keyclicks. Are they RT?

    No. It's quite OK to wait 1/10th of a second before
    Emacs is scheduled. This really is not something we
    care about a lot (OK, we do, but we don't have to).

    The Linux scheduler lets a nice +19 task get it's
    timeslice when Emacs has run out of it's, regardless
    of whether the user pressed a key or not.

    An RT task will always get priority, regardless of
    CPU time used and/or other crap.

    I guess the difference you're looking for is absolute
    vs. dynamic priority. The RT tasks have absolute and
    static priority while other tasks have a scheme of
    dynamic priorities where everyone gets a turn.

    > I'm not being sarcastic here, it's quite difficult to determine what
    > "soft RT" should look like and I know it's a real problem for some
    > people. But Linux should provide a real solution, not repeat the
    > mistakes of others.

    In my view, RT tasks really should have absolute
    priority over non-RT tasks and static priority
    within it's own class.

    This inherently carries the problem of priority
    inversion with it, so we need to find a solution
    to it.

    cheers,

    Rik -- slowly getting used to dvorak kbd layout...
    +-------------------------------------------------------------------+
    | Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
    | Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
    +-------------------------------------------------------------------+


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:45    [W:2.936 / U:0.136 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site