[LAU] Issue with the priority of the sound cards using rtirq

[Rui Nuno Capela]

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 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.


> 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 :)

>
> [*] other than scanning the kernel source code for the names of all
> possible soundcard driver irq processes, making a list and matching
> against that - it would work but it would depend on those names not
> changing, and of having the list that matches the kernel you are running.

that might be the case. add to that that the ps command name is 
truncated to 15chars which confuses the matching of some soundcard 
module names or labels, often down to 4 or 5 chars eg. "hda_" instead of 
full "hda_intel", or worst, "ice1" for both "ice1712" and "ice1724"...

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