28 Jul
2004
28 Jul
'04
7:16 a.m.
* Bill Huey <bhuey(a)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