9 Aug
2004
9 Aug
'04
5:05 p.m.
On Mon, 09 Aug 2004 14:05:26 -0400
Lee Revell <rlrevell(a)joe-job.com> wrote:
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.
No, i will not put a verbatim copy of this onto the wiki. I will try to
extract the relevant information.
This text describes the Solaris implementation of interrupt threads
vs. the traditional method. It applies very well to Ingo's patch.
Ok
These <it>kernel
threads</it> can be created on the fly and are assigned a higher
priority than all other types of threads.
This seems to be not true for the threaded IRQ handlers in VP [top
extract]:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
118 root 5 -10 0 0 0 S 0.0 0.0 0:00.00 IRQ 5
mango:~# chrt -p 118
pid 118's current scheduling policy: SCHED_OTHER
pid 118's current scheduling priority: 0
Or do chrt and top print wrong infos? Or do i just read them wrong? I'm
especially amazed about the SCHED_OTHER.
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.
Hmm, isn't it the case that the traditional IRQ handler blocks all
further IRQ's until it is done? I suppose there was a hierarchy of some
kind. I read about the ipl in the text you quoted but didn't understand
it really..
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.
Yes, this makes sense..
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.
Me neither, but it makes sense..
--
Palimm Palimm!
http://affenbande.org/~tapas/