Subject: Re: wiki page (was: Re: [linux-audio-user] dipping toes in 2.6 waters)
From: Lee Revell (rlrevell_AT_joe-job.com)
Date: Mon Aug 09 2004 - 21:05:26 EEST
On Sun, 2004-08-08 at 06:45, Florian Schmidt wrote:
> On Sun, 08 Aug 2004 01:51:28 -0400
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
This archive was generated by hypermail 2b28 : Mon Aug 09 2004 - 21:08:33 EEST