Messages in this thread | | | Date | Thu, 29 Jul 2004 20:21:10 +0200 | From | Ingo Molnar <> | Subject | Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch |
| |
* 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 - 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/
| |