> 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/