Re: [LAD] rtirq script is broken with 2.6.31

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Davis wrote:
> On Fri, Aug 7, 2009 at 9:32 AM, Rui Nuno Capela<rncbc@email-addr-hidden> wrote:
>
>> this time however it looks that you can actually improve things when
>> several device drivers are hanging on a irq line. that is, one can tune
>> up the one and only the one actually intended (eg. "snd" => "irq/17-HDA
>> Inte" and nothing else)
>
> not so fast. unless things have *really* changed in h/w (and they may
> have) when the CPU sees a IRQ 17, it will still have to execute at
> least every handler until one of them says "yes it was me", and
> depending on the kernel design right now, possibly all of them. ergo,
> its not clear you will benefit from raising the priority of one versus
> the others.

I don't know all the details of the implementation; NTL I take it that a
lower priority IRQ handler can be preempted in favor of one with a
higher priority even if they're on the same IRQ line.

It won't do any good for level-sensitive IRQs, but with hardirq
preemption fasteoi does replay edge interrupts:
If an IRQ arrives, rt-linux sends an EOI. If the edge IRQ comes again
(while linux is processing the same IRQ), non-threaded handler marks IRQ
to be replayed, then masks it and sends EOI. When the thread awakes, it
unmasks the IRQ before handle_IRQ_event, so that it can catch the next
edge IRQ.

> i'd be interested in hearing/reading the arguments for
> per-driver threads for this - on the face of it it seems rather odd to
> me.

Here's what Thomas Gleixner wrote announcing 2.6.31-rc4-rt1:

    Another interesting detail is that the new forced threaded code
    uses per device threads instead of per interrupt line threads as
    we have done in the past. This was just a logical consequence of
    the per device thread (voluntary threading) infrastructure in
    mainline and allows us now to share an interrupt line between a
    hardirq based handler and a threaded handler device. One use case
    which comes to my mind is AT91 which shares the timer and the
    serial port interrupt; we now can solve that problem w/o nasty
    hacks by requesting a threaded handler for the serial port which
    shuts up the serial device interrupt in the hard interrupt handler
    part.

..for further details just ask the rt-linux ML or attend the eleventh
Real-Time Linux Workshop on September 28 to 30, in Dresden, Germany ;)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkp+TJcACgkQeVUk8U+VK0KT3wCgiL6MNDeYuY3EuTr4yhMoX9/v
/6sAoJdFjkIwDiHxFs9MPPJfWvQbaAl6
=pJjI
-----END PGP SIGNATURE-----
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Sun Aug 9 08:15:02 2009