[LAU] rtirq, kernels >= 3.2 and udev

[Rui Nuno Capela]

On 05/09/2012 02:03 AM, Fernando Lopez-Lezcano wrote:
> Hi all (and Rui),
>
> As noted in another thread I found out that the naming of the irq
> processes of pci soundcards has changed with kernels >= 3.2 to be
> uniform and predictable. That made it possible to change rtirq so that
> (at least for pci cards) only the irq process that corresponds to the
> soundcard gets an elevated priority - this was not completely reliable
> before.
>
> Another nice (very nice I'd say) side effect of this change is that now
> udev can be trivially used to change the priorities of soundcards
> dynamically. I tested this while running 3.2.16-rt27 on a Fedora 14
> system. I removed "snd" and "usb" of the rtirq sysconfig file so that it
> would not touch those and rebooted. My hda_intel got the priority I
> wanted, inserting (or removing) a usb or a pci-express card with a
> Multiface II worked as well. Right now my simple script does not try to
> order priorities, it just sets them to a fixed one. But well, it is a
> start... Code attached (the udev rule goes into /etc/udev/rules.d/ in my
> system)...
>
> This simple script also returns the priority of the usb irq for the
> soundcard to 50 (the default) when the card is unplugged, but it does
> not check for multiple cards (ie: even if another soundcard is still
> using the same irq process it downgrades its priority), this should be
> fixed.
>


> Feedback appreciated.
> -- Fernando
>
> PS: Another rtirq script in /etc/pm/sleep.d/ could save the current
> priorities before a suspend and restore them after a resume - that does
> not happen currently.

what about just `rtirq restart` on the sleep.d script (on thaw|resume) ?

warning. there's no state salvage being done on bad old rtirq script. in 
fact `rtirq stop` is a plain nop by default, unless RTIRQ_RESET_ALL=1 is 
set (cf. /etc/rtirq.conf aka. /etc/sysconfig/rtirq) which makes all 
target irq service threads to reset to rtprio=50 but also to "normal" 
scheduling class(SCHED_OTHER). might not on par with the times :)

note that `rtirq restart` is actually the same function as `rtirq stop` 
immediately followed by `rtirq start`. however, as s the very same irq 
service threads are at stake, this whole remark might not be an issue 
after all:)

byee
-- 
rncbc aka Rui Nuno Capela
rncbc at rncbc.org