Messages in this thread | | | Date | Thu, 27 Apr 2023 15:14:47 +0200 | Subject | Re: Unfair qspinlocks on ARM64 without LSE atomics => 3ms delay in interrupt handling | From | Jan Kiszka <> |
| |
On 26.04.23 23:29, Thomas Gleixner wrote: > On Wed, Apr 26 2023 at 12:03, Zdenek Bouska wrote: >> following patch is my current approach for fixing this issue. I introduced >> big_cpu_relax(), which uses Will's implementation [1] on ARM64 without >> LSE atomics and original cpu_relax() on any other CPU. > > Why is this interrupt handling specific? Just because it's the place > where you observed it? > > That's a general issue for any code which uses atomics for forward > progress. LL/SC simply does not guarantee that. > > So if that helps, then this needs to be addressed globaly and not with > some crude hack in the interrupt handling code.
My impression is that the retry loop of irq_finalize_oneshot is particularly susceptible to that issue due to the high acquire/relax pressure and inter-dependency between holder and waiter it generates - which does not mean it cannot occur in other places.
Are we aware of other concrete case where it bites? Even with just "normal" contented spin_lock usage?
> >> Anyone has a better idea how to solve this issue properly? > > Use hardware with LSE atomics :)
That would generate tons of waste of current electronic devices without it - not very fashionable anymore. ;)
Jan
-- Siemens AG, Technology Competence Center Embedded Linux
| |