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. 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. 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. > Thanks, > Gratian Sebastian
