>I don't think this "deadlock" is actually a real problem. Unless there
>is some bug in the FS/VFS, a process should not call schedule() while
>it holds some lock. Instead, if it has to wait, it should release the
See sys_read: determine where the kernel_lock is released.
>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.
>way, the problem is not with the SCHED_IDLE patch.
Of course it is.
>
>Consider the following scenario:
>- SCHED_OTHER process bangs on the FS
>- low-priority RT process computes primes or whatever
>- high-priority RT process occasionally wakes up, reads a device and
> uses the FS.
>
>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.
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".
-
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/