Messages in this thread | | | Date | Wed, 28 Jul 2004 16:52:11 -0400 | Subject | Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch | From | Scott Wood <> |
| |
On Wed, Jul 28, 2004 at 08:45:47AM +0200, Ingo Molnar wrote: > 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.
The difference is that latency issues are isolated to code which uses the locks with bad critical sections. If some random driver holds an internal lock for a few milliseconds, it won't slow down anything that doesn't interact with the driver (either directly or by blocking on something else that interacts with the driver). Turning the spinlocks into mutexes doesn't eliminate the need for lock-breaking; it just lets the lock-breaking effort be concentrated on the core mutexes, so you don't need to fix *all* of the bad critical sections to see a reduction in worst case latency of common code.
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. Otherwise, you run the risk of some special code path (such as out-of-memory, perhaps) that didn't get hit in latency testing showing up and causing problems for a RT task that doesn't need memory, and doesn't go anywhere near the lock in question. How much this matters depends on how hard the RT one needs is.
Another is that the observed latencies of many apps is likely to go down faster than when squashing each individual latency in the system as it shows up. Said squashing can (and should) still occur, but at least some apps will not have to wait.
-Scott - 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/
| |