[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <AS1PR10MB5675DC0F58D71A8C82B49B14EB8B9@AS1PR10MB5675.EURPRD10.PROD.OUTLOOK.COM>
Date: Tue, 28 Mar 2023 09:39:38 +0000
From: "Bouska, Zdenek" <zdenek.bouska@...mens.com>
To: Will Deacon <will@...nel.org>,
Catalin Marinas <catalin.marinas@....com>
CC: Thomas Gleixner <tglx@...utronix.de>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Kiszka, Jan" <jan.kiszka@...mens.com>,
"linux-rt-users@...r.kernel.org" <linux-rt-users@...r.kernel.org>,
Nishanth Menon <nm@...com>, Puranjay Mohan <p-mohan@...com>
Subject: Re: Unfair qspinlocks on ARM64 without LSE atomics => 3ms delay in
interrupt handling
> > A longer cpu_relax() here would improve things (on arm64 this function
> > is a no-op) but maybe Thomas or Will have a better idea.
>
> I had a pretty gross cpu_relax() implementation using wfe somewhere on
> LKML, so you could try that if you can dig it up.
Do you mean cpu_relax() implementation from this email [1] from
Fri, 28 Jul 2017 ?
I tried to rebase it on recent Linux, but it did not even boot for me.
Only this was printed:
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[ 0
But cpu_relax() implementation from [1] fixes my problem if I use it
only in irq_finalize_oneshot().
[1] https://lore.kernel.org/lkml/20170728092831.GA24839@arm.com/
Zdenek Bouska
--
Siemens, s.r.o
Siemens Advanta Development
Powered by blists - more mailing lists