Subject: Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch
From: Ingo Molnar (mingo_AT_elte.hu)
Date: Thu Jul 29 2004 - 21:21:10 EEST
* Scott Wood <scott_AT_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
This archive was generated by hypermail 2b28 : Fri Jul 30 2004 - 10:34:44 EEST