On 05/03/2012 12:51 AM, Rui Nuno Capela wrote:
On 05/03/2012 07:25 AM, Fernando Lopez-Lezcano wrote:
On 05/02/2012 12:19 AM, Jeremy Jongepier wrote:
On 05/01/12 20:32, Fernando Lopez-Lezcano wrote:
(I don't seem to find the start of the thread in my mailbox)
ohci_hcd is there is you specify usb in the list of priorities rtirq
needs to raise. And nvidia is there probably because it shares an
interrupt with a real soundcard. Rtirq does not raise the priority of
only the soundcard, but everything that uses the interrupt that the
soundcard uses.
Afaik this is not true. The threadirqs kernel option (or a real-time
kernel) creates bottom halves (or tasklets, or softirqs) of each device
that has or shares an IRQ. So in Ralf's case four devices share IRQ 18,
two USB hubs, a soundcard and a graphics card. Each of those devices
gets its own specific softirq which then can get prioritized with rtirq
accordingly. Default rtprio is 50 afaik, so nvidia should get rtprio 50
and not 82.
That's how we all would like things to work, regretfully that is not how
things actually work.
AFAIK it is not possible (or simple) to raise _just_ the soundcard
as it
is impossible to know which irq process corresponds to a soundcard (and
which one does not). That is because the labeling of the irq process
names in the ps listing is arbitrary.
It is not arbitrary, the softirqs get specific names derived from the
loaded kernel module for that device iirc.
For soundcard drivers there is no convention for naming the irq process
that services its interrupt. The name of the irq process does not match
the name of the kernel module (which would be an obvious choice). The
ascii that is printed by ps is defined in the kernel code for each
driver, and driver authors pick different names that are not consistent.
That means you can't pattern match for the right irq process if the
interrupt number is shared by several devices.
It would be possible to pattern match if, for example, all soundcards
used a "snd_" prefix for the name of the irq process, but that is not
the case (at least until last time I looked at the kernel code for this
very same reason).
So the graphics card gets a
label 18-nvidia, the soundcard 18-snd_hdsp and both usb hubs
18-ohci_usb. And it is those labels that rtirq uses to set the rtprio
for the different softirqs.
The rtirq code does the following (simplified):
- rtirq gets the irq number from /proc/asound/cards
- that number is used to search the output of ps looking for matches
with that particular irq number
- there is no way to tell which irq process corresponds to a soundcard,
rtirq does not try AFAICT
- so, all irq processes that match the number get the elevated priority
For example, in my laptop, from /proc/interrupts:
16: 2551 516 113 95 IO-APIC-fasteoi nouveau, snd_hda_intel, mmc0
rtirq happily gives them 75, 74 and 73:
222 FF 75 - 115 0.0 S irq/16-nouveau
11077 FF 74 - 114 0.0 S irq/16-snd_hda_
11082 FF 73 - 113 0.0 S irq/16-mmc0
Please let me know if there is a way to, given an irq number, know what
is the pid of the irq process that services that irq number for a
particular _soundcard_, I have found no way of doing that so far[*].
you seem to be using an old rtirq version--the latest maybe found here:
http://www.rncbc.org/jack/#rtirq
I'm using:
rtirq-20111007-1.fc14.ccrma.i686
seems to be the latest.
i believe the newer rtirq already addresses the above: the only irq line
that shall get prioritized will be the one of hda-intel soundcard
(irq/16-snd_hda), as long you DON'T include "nouveau" nor "mmc" on the
RTIRQ_NAME_LIST, while "snd" stays there put.
----
# IRQ thread service names
# (space separated list, from higher to lower priority).
RTIRQ_NAME_LIST="rtc snd usb i8042"
----
Note that in all other cases other than soundcards rtirq looks for the
name, not the number of the irq (for example for usb the names are well
known and unique and hardwired into rtirq).
it looks for name particle _and_ number, last time i've checked :)
Ah, yes, right! But see below for why this fails.
When searching for "snd" it finds this:
# grep irq /proc/asound/cards | sed 's/\(.*\) at .* irq \(.*\)/\2 \1/'
44 HDA Intel
16 HDA NVidia
From that information it eventually then calls (output of bash -x):
+ rtirq_exec_num start snd HDA-Intel 75 16
+ ACTION=start
+ NAME1=snd
+ NAME2=HDA-Intel
+ PRI2=75
+ IRQ=16
++ echo :rtc:
++ sed 's/ /:/g'
++ grep :snd:
+ '[' -n '' ']'
++ echo :8:
++ grep :16:
+ '[' -z '' ']'
++ ps -eo pid,comm
++ egrep -i IRQ.16.HDA-Inte
++ awk '{print $1}'
This is where it fails, it tries to match irq number and name and fails.
Why? Because there is no fixed relationship between what is in
/proc/asound/cards and the names of the irq processes themselves. In
this particular case ps gives (with beautiful truncation added):
12665 irq/16-snd_hda_
which has nothing to do with (not case sensitive):
"hda-inte"
which is what rtirq searches for (and this is the best it can do with
the information it has). Then it falls back to "2.6.31 compatibility"
mode which only searches for irq number and then all three irq processes
are elevated in priority.
The failure is because there is (as I pointed out) no fixed greppable
relationship between the textual information found in /proc/asound/cards
and the names of the processes that service the interrupts - I have
looked at the relevant kernel code and the names of the processes are
arbitrary strings. It may work in some cases if the names match, but it
does not in the generic case. It certainly does not work for
snd_hda_intel in my machine. I believe others are seeing the same problem.
I'd love to find a way to reliably map from the information you get from
/proc/asound/cards to the pid of the right irq process...
-- Fernando
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
