On Sun, 2004-08-08 at 06:45, Florian Schmidt wrote: > On Sun, 08 Aug 2004 01:51:28 -0400 > http://www.affenbande.org/~tapas/wiki/index.php?Low%20latency%20for%20audio%20work%20on%20linux%202.6.x Here is an excerpt from "Unix Internals" by Uresh Vahalia that explains the situation much better than I could. I am not sure what the copyright implications of posting this are, possibly it is short enough to be OK, but I will let you be the judge of whether to post it on the wiki. This text describes the Solaris implementation of interrupt threads vs. the traditional method. It applies very well to Ingo's patch. "Interrupt handlers often manipulate data shared by the rest of the kernel. This requires the kernel to synchronize access to shared data. In traditional UNIX, the kernel achieves this by raising the <it>interrupt priority level (ipl)<it> to block relevant interrupts while executing code that accesses such data (...). This model has many drawbacks ... Interrupts are important and urgent events, and blocking them degrades performance in many ways ... Solaris replaces the traditional interrupt and synchronization model with a new implementation [Eykh 92, Klei 95] that aims to improve performance (...) it does not use IPLs for interrupts... it employs a set of kernel threads to handle interrupts. These <it>kernel threads</it> can be created on the fly and are assigned a higher priority than all other types of threads. They use the same synchronization primitives as other threads and thus can block if they need a resource held by another thread. The kernel blocks interrupts only in a few exceptional situations, such as when acquiring the mutex lock that protects a <it>sleep queue</it>. Although the creation of kernel threads is relatively lightweight, it is still too expensive to create a new thread for each interrupt. The kernel maintains a pool of interrupt threads, which are preallocated and partially initialized. By default, this pool contains one thread per interrupt level for each CPU, plus a single systemwide thread for the clock." My explanation: Basically, with non-threaded interrupts, anytime an interrupt occurs the interrupt handler runs immediately, blocking additional interrupts from the same device while it is running. This means than an interrupt handler can interrupt another interrupt handler, say, if we get a disk i/o completion in the middle of snd_pcm_period_elapsed. With threaded interrupts, an interrupt arriving from the disk controller does not immediately cause the disk irq handler to run, interrupting whatever was going on, but marks the disk irq thread as ready to run. Since interrupt threads run at the highest priority, this will usually cause the disk irq handler to be scheduled and run immediately, unless we are executing a *non-threaded* interrupt handler. This is the advantage of the mixed model - where the soundcard interrupt handler would previously have been interrupted, in this case the disk irq handler will run as soon as the soundcard irq handler exits. By default, if all irqs are threaded, all the threads run at the same priority. This means that if we get interrupts from both the soundcard and disk while a third handler is running (say the timer). both will be queued, and possibly the disk irq thread will get scheduled before the soundcard irq thread, leading to xruns. I believe you could achieve the same result as setting the soundcard irq non-threaded by having all irqs threaded, and setting the priority for the soundcard interrupt handler thread higher than the others. I have not tested this. Lee
