[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-rt-users
Subject:    Re: Re: irq thread latency caused by softirq_ctrl.lock contention
From:       Gratian Crisan <gratian.crisan () ni ! com>
Date:       2021-09-22 19:16:39
Message-ID: 877df87754.fsf () ni ! com
[Download RAW message or body]


Sebastian Andrzej Siewior writes:

> On 2021-09-15 17:59:50 [-0500], Gratian Crisan wrote:
>> Hi guys,
> Hi,
>
> …
>> The 'irq/102-atomicc-248' irq thread is our high priority data
>> acquisition thread. The additional pi boost and context switch seems to
>> account for the main differences I'm seeing versus 4.14-rt. This race +
>> pi boost happens with other lower priority irq threads too but the
>> ksoftirq case is the most common one.
>> 
>> I would appreciate any thoughts on how/if we could improve this?
>
> It appears to be a consequence of the new softirq design/ handling.
> Earlier we could have multiple softirqs running in parallel on a single
> CPU (as in NET_RX and NET_TX).
> With the new design only one softirq can be handled at a time resulting
> in a full synchronisation at local_bh_diable() time by the lock you
> mention in subject.

Makes sense.

> In your case it appears that irq/102-atomicc is force-threaded and
> therefore requires to disable BH before its execution. This is just to
> mimic what upstream does in terms of locking and to ensure that BH
> invocation happens after the threaded interrupt ended.

Yes, good catch.

> If there is nothing special about this interrupt handler (in terms of BH
> handling) you could request a threaded handler for the IRQ. The manually
> threaded handler do not disable BH before their invocation.
>

I appreciate the insight. I think this will solve our problem.

>
> Sebastian

Thanks again,
    Gratian
[prev in list] [next in list] [prev in thread] [next in thread]