Messages in this thread | | | Date | Mon, 9 Nov 1998 20:33:28 +0100 (CET) | From | Rik van Riel <> | Subject | Re: Schedule idle |
| |
On Sun, 8 Nov 1998 yodaiken@chelm.cs.nmt.edu wrote: > Richard Gooch writes: > > >lock, call schedule() and then re-aquire the lock. That's the friendly > >way. The alternative is that we implement priority inversion. Either > > You must mean: "implement priority inheritance" -- "priority inversion" is the > error, "priority inheritance" is so-called "fix".
> Both are symptoms of bad design. The Linux kernel does not implement > a priority scheme for access to shared resources other than the processor. > There are many good reasons for this: among them, priority schemes don't > work in complex systems. By introducing fake real-time into the kernel, > you introduce an error based on the following contradiction: > Linux kernel assumes that a kernel mode thread should progess > until _it_ (the thread) decides to reschedule > > Priority based RT assumes that the highest priority runnable > process will advance at any time. > > If the OS tries to believe both propositions at the same time it will die.
Not neccesarily. There are certain things you can do do avoid this situation. Firstly, RT processes usually don't take up loads of CPU time. If they do, you're better off with a separate system anyway; you're right on that.
OTOH, I have been running RT processes for a long time now (can you say 1.3) without actually experiencing any of the problems you mentioned.
> >way, the problem is not with the SCHED_IDLE patch. > > Of course it is.
The SCHED_IDLE idea is just an extension of the realtime paradigm. I take it you're not really serious about wanting to back _that_ out of the kernel.
Hint: you don't need the SCHED_IDLE patch to bump into the priority inversion scheme, hence the problem is somewhere else.
> >Consider the following scenario: > >- SCHED_OTHER process bangs on the FS
Which is fully threaded, except for some properly protected areas.
> >- low-priority RT process computes primes or whatever > >- high-priority RT process occasionally wakes up, reads a device and > > uses the FS.
Priority inheritance would solve the problem.
> >Just as in your example, the important RT process gets locked out of > >the FS if schedule() is called with locks held. So, the problem isn't > >with SCHED_IDLE, it's elsewhere. > > The problem is that you are introducing a complex mechanism to do > something unspecified.
The 'something unspecified' means solving possible problems with priority inversion that might be hidden somewhere in the code.
> Spell out what "important RT" means precisely and you will be in a > position to make your code work. If you want a completely > preemptable kernel, you have your work cut out for you. God alone > knows what it means for a high priority RT task to "use the FS".
Uhmm, this is rather vague -- what is the hidden message in this paragraph?
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/
| |