9 Aug
2004
9 Aug
'04
5:24 p.m.
On Mon, 2004-08-09 at 17:00, Florian Schmidt wrote:
I think Linux does not have ipls as such. When an interrupt handler is
running it blocks further interrupts from the same source, but without
the voluntary preempt patch, an interrupt from the disk will interrupt
the soundcard interrupt handler. If you were to extend this scheme to
support more than one priority (as opposed to 'this interrupt source' vs
'other interrupt source'), you would have IPLs.
I think that threading all interrupts and setting relative priorities
would give you IPLs on Linux. More testing is required.
Lee
On Mon, 09 Aug 2004 14:05:26 -0400
Lee Revell <rlrevell(a)joe-job.com> wrote:
OK. I am going to plug the book however because it's so good:
http://www.amazon.com/exec/obidos/tg/detail/-/0131019082?v=glance.
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 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.
You are correct, they run at the same elevated priority as all kernel
threads, not higher. This would explain why X activity can delay the
interrupt handlers with the default settings - on Debian the X server
runs at nice -10. I am pretty sure that one patch series (-L or -M) ran
the interrupt threads reniced to -51.
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..