Messages in this thread | | | Date | Wed, 28 Jul 2004 08:45:47 +0200 | From | Ingo Molnar <> | Subject | Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch |
| |
* Bill Huey <bhuey@lnxw.com> wrote:
> There are also other problem with moving to a largely sleeping mutex > style kernel, dead lock detection becomes sorely needed. Current > spinlock detection methods are probably going to be useless in a > system like this. [...]
i have another worry with the 'everything is a mutex' concept. Currently we still do have a number of 'central' locks such as dcache_lock, or the SLAB locks. So even if all (but the scheduling) spinlocks are converted to sleeping mutexes what do you gain? A high-prio RT task will get to execute userspace instructions almost immediately, but any kernel functionality use of this RT thread might still be blocked by a priority inversion problem. So the same type of latency problems that we are detecting and solving currently will occur on a mutex-based system as well - if the RT application wants to use kernel functionality.
so why dont we keep the spinlocks [on UP, nonpreemptible sections] and just let the kernel finish its work and get to a fully lock-quiescent state ASAP where we can reschedule? It's not like that a high-prio RT task can avoid this situation with any guarantee, as long as these central locks remain. (in fact it would have to do this processing with higher overhead, because the lowprio thread that got preemption needs to be boosted, scheduled, unscheduled and the high-prio task needs to schedule again.)
i'd agree with turning most of the finegrained per-task (non-irq-safe) spinlocks into mutexes (or spin-mutexes). But the central locks that an RT task would likely hit need to remain spinlocks i believe.
plus there are central mutexes too that are in 'hiding' currently but could cause latencies just as much.
Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |