7 Aug
2009
7 Aug
'09
12:04 p.m.
Rui Nuno Capela wrote:
Robin Gareus wrote:
not so deeper, more than a simple regex fix but some bash trickery now
added: please, try the attached patch (rtirq-20090807-1.diff) and tell ;)
cheers
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
Rui Nuno Capela wrote:
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...
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