Re: [PATCH] PCI: iproc-msi: Bound events handled per IRQ

[Eugen Hristev]

On 10/30/26 19:22, Manivannan Sadhasivam wrote:
> On 2026-10-16 23:10 +0300, Eugen Hristev wrote:
>> On 10/16/26 21:21, Bjorn Helgaas wrote:
>>> On Fri, Oct 16, 2026 at 03:18:53PM +0300, Eugen Hristev wrote:
>>>> Limit each iProc MSI parent IRQ to 16 event-queue entries.
>>>>
>>>> A continuously fed queue could otherwise keep the chained handler running
>>>> and starve other work. The budget still drains pending events and lets the
>>>> next parent interrupt continue processing, improving fairness and bounding
>>>> interrupt-handler latency.
>>>>
>>>> Without this starvation avoidance, one CPU can stall indefinitely
>>>> in the loop and not serve other interrupts, timers, etc.
>>>>
>>>> While testing it with an Ethernet NIC,  when too many MSI interrupts
>>>> come in, CPU might get starved:
>>>>
>>>> Connecting to host 192.168.30.1, port 5201
>>>> [  5] local 192.168.30.2 port 52586 connected to 192.168.30.1 port 5201
>>>> [ ID] Interval           Transfer     Bitrate         Retr  Cwnd
>>>> [  5]   0.00-1.00   sec   240 MBytes  2.01 Gbits/sec    2    334 KBytes
>>>> [  5]   1.00-2.00   sec  63.2 MBytes   531 Mbits/sec    1   1.41 KBytes
>>>> [  5]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
>>>> [  5]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
>>>> [  5]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
>>>> [  5]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
>>>> [  5]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
>>>> [  5]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
>>>> [  5]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
>>>> [  177.568497] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
>>>> [  177.568913] rcu:     0-...!: (1 GPs behind) idle=28ac/1/0x4000000000000002 softirq=28922/28930 fqs=1
>>>> [  177.569457] rcu:     (detected by 1, t=5256 jiffies, g=21629, q=819 ncpus=4)
>>>> [  177.569870] Sending NMI from CPU 1 to CPUs 0:
>>>>
>>>> With this bounded approach, IRQ handler will complete and continue
>>>> to serve MSI events on the next handler invocation.
>>>
>>> Is there something unique about iproc that makes this an issue, or do
>>> we need to worry about this in every MSI interrupt handler?
>>>
>> This is not specific to iPROC, so in theory it can happen to any other
>> MSI interrupt handler. If the handler has no way to break the loop, and
>> the condition that generates the MSI IRQ happens continuously, the same
>> situation will happen.
> 
>> Some other drivers e.g. take the IRQ state into a local variable, do the
>> task, clear it up, and don't care to read it again, like the iPROC is
>> doing, unless another MSI fires.
>>
> 
> You should rework the iproc handler to read head and tail outside of the loop
> and handle the recorded events inside the loop. This will avoid using any
> arbitrary max event limit and allow other handlers to also run.

Hi Mani,

Thanks for the feedback, I changed it as you said, sent a v2.

Eugen>
> - Mani
>