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:1.463 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site