Re: [LAD] rtirq script is broken with 2.6.31

Robin Gareus wrote:
> Rui Nuno Capela wrote:
>
>> this issue on 2.6.31-rt has been already reported privately and i'll get
>> to it as soon i get back home from vacation. meanwhile, it really looks
>> like a regex trickery is all that's needed,
>
> I'm not so sure, Since 2.6.31 it is also possible to raise the priority
> not by IRQ number but by /device-driver/.
>
> ie:
> PID CLS RTPRIO NI PRI %CPU STAT COMMAND
> 9092 FF 89 - 129 0.4 S< irq/17-HDA Inte
> 1447 FF 50 - 90 0.1 S< irq/17-uhci_hcd
> 9093 FF 50 - 90 0.0 S< irq/17-ohci1394
>
> ..but of course that's also just regexp trickery ;)
>
> Note that the kernel limits the IRQ process name to 15 chars.
> "HDA Inte" won't read "HDA Intel" even when using `ps -w..`
>
> But '/proc/interrupts' says:
> 17: 17215454 873204 IO-APIC-fasteoi uhci_hcd:usb3, HDA Intel,
> ohci1394
>
>> keeping in mind that
>> backward compability with pre-2.6.31-rt kernels is in order (eg. i do
>> still run on 2.56.29.5-rt22 for which the current rtirq script is
>> perfect, of course)
>
>> as a quick suggestion, try this for instance (re. line 120):
>> PIDS=`ps -eo pid,comm | egrep "(IRQ.${IRQ}|irq\/${IRQ}\-.+)\$" | awk
>> '{print $1}'`
>
>
> That works, but raises all devices on a given IRQ-line and results in:
> PID CLS RTPRIO NI PRI %CPU STAT COMMAND
> 1447 FF 88 - 128 0.1 S< irq/17-uhci_hcd
> 9092 FF 87 - 127 0.4 S< irq/17-HDA Inte
> 9093 FF 86 - 126 0.0 S< irq/17-ohci1394
>

which is the exact and old behavior of rtirq for kernel-rt < 2.6.31-rt.

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 just a simple regex oneliner anymore and i'm afraid it might need a
deeper retouch...

>
>>> [..]
>>>
>>> Yes I'm also baffled at the high PIDs for IRQs. I hazard a guess that
>>> those are a result of a suspend/resume cycle; and I'll check later if
>>> the chrt settings do persist after a suspend/resume.
>
> It looks like the guess was correct. The PIDs change after
> suspend/resume and the chrt settings are retained here.
>
> Take your time, and enjoy the holiday.

sure, tks

-- 
rncbc aka Rui Nuno Capela
rncbc@email-addr-hidden
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev