Paul Davis wrote:
On Tue, 2007-04-10 at 14:34 +0200, Pieter Palmers wrote:
I'm also wondering why/whether threaded IRQ's can't be software-demuxed
in the kernel. A very basic interrupt handler like this:
handle_irq() {
switch(irq_source) {
case HDA:
set_my_prio(high);
hda_handle_irq();
case 1394:
set_my_prio(low);
1394_handle_irq();
}
}
Ingo's threaded IRQ stuff does something like this, but I don't quite
know the details of it. I'm under the impression that it allows setting
the priority of the 'handle_irq()' but not of the dispatched IRQ handlers.
yes, thats correct. the priority of the IRQ itself is based in h/w, and
is not affected by the scheduling class or priority of the kernel task
that runs the *_handle_irq(). the point of ingo's changes are that
*_handle_irq() runs in a dedicated task/thread per IRQ at a (relatively)
fixed priority.
I think we're not on the same track here...
This is how I understand things:
The IRQ priorities are indeed hardware fixed, in the sense that if two
IRQ's occur simultaneously, that the order of handling them is hardware
based. [=what you say]
The IRQ handler 'vectors' are called by the hardware, and these call the
IRQ handler functions registered in the kernel. Ingo's patch makes these
handler functions run in separate threads that are scheduled at a
certain priority. These IRQ handler functions then determine what module
the IRQ is for/from, and run the IRQ handler for that module, at the
same priority as it was scheduled itself.
What I propose is that the IRQ handler priority can be set for each
module irq handler, instead of for each 'global' irq handler.
Example:
What I see on my laptop is:
$ cat /proc/interrupts:
...
9: 2210709 XT-PIC-XT ipw2200, Intel 82801DB-ICH4,
Intel 82801DB-ICH4 Modem, eth0
...
$ ps -eo comm,class,rtprio | grep IRQ-9
IRQ-9 FF 50
What I would like to see is:
$ ps -eo comm,class,rtprio | grep IRQ-9
IRQ-9-ipw2200 TS -
IRQ-9-snd FF 50
IRQ-9-eth0 TS -
That would restrict the critical path whenever IRQ-9 is called to the
kernel's dispatch function for the interrupt.
Greets,
Pieter
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
