Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch

Ingo Molnar
2004-07-29T18:24:54Z

* Scott Wood <scott@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