9 May
2012
9 May
'12
8:23 p.m.
On 05/09/2012 07:38 AM, Rui Nuno Capela wrote:
On 05/09/2012 02:03 AM, Fernando Lopez-Lezcano wrote:
Yes, probably not on par with the times as when using threaded irqs they
run by default SCHED_FIFO and with priority = 50 (I don't know if the
priority is fixed or can be changed by, say, a kernel boot parameter).
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:)
I like the idea of using udev for setting priorities of soundcard
interrupts as that allows you to run with the least amount of high
priority processes (only for the cards actually present). In particular
for usb cards only the usb irq that corresponds to the card needs to be
raised and then it returns to normal when the card is unplugged.
-- Fernando