29 Jul
2004
29 Jul
'04
4:35 p.m.
* Scott Wood <scott(a)timesys.com> wrote:
Those critical sections where lock-breaking has been
done can be
converted back into spinlocks. Essentially, mutexes would be used for
"untrusted" locks, as opposed to using spinlocks just where they're
absolutely necessary. Over time, the set of trusted locks would
presumably go up, though we'd have to be careful to make sure people
know that they need to be especially careful of latency issues when
they touch code that uses such locks.
One of the main benefits is that it significantly increases the RT
guarantees for those users for whom the RT portion of their app can be
verified as only using a limited, testable/auditable subset of kernel
paths. [...]
ok, i see - this makes 100% sense. I'm wondering how intrusive such an
all-preemptive patchset is? There are some problems with per-CPU data
structures on SMP. Right now holding a spinlock means one can use
smp_processor_id() and rely on it staying constant in the critical
section. With a mutex in the same place all such assumptions would
break. Is there some automatic way to deal with these issues (or to at
least detect them reliably?).
Ingo