Messages in this thread | | | Date | Tue, 10 Nov 1998 13:50:24 +0100 (CET) | From | Rik van Riel <> | Subject | Re: 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/
| |