Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Thomas Gleixner <tglx@linutronix.de>
To:     "Bouska, Zdenek" <zdenek.bouska@siemens.com>,
        Will Deacon <will@kernel.org>,
        Catalin Marinas <catalin.marinas@arm.com>
Cc:     "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "Kiszka, Jan" <jan.kiszka@siemens.com>,
        "linux-rt-users@vger.kernel.org" <linux-rt-users@vger.kernel.org>,
        Nishanth Menon <nm@ti.com>, Puranjay Mohan <p-mohan@ti.com>
Subject: Re: Unfair qspinlocks on ARM64 without LSE atomics => 3ms delay in
 interrupt handling
In-Reply-To: <AS1PR10MB567534190B05A4493674173BEB659@AS1PR10MB5675.EURPRD10.PROD.OUTLOOK.COM>
References: <AS1PR10MB567534190B05A4493674173BEB659@AS1PR10MB5675.EURPRD10.PROD.OUTLOOK.COM>
Date:   Wed, 26 Apr 2023 23:29:45 +0200
Message-ID: <87pm7qxrg6.ffs@tglx>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

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.

> Anyone has a better idea how to solve this issue properly?

Use hardware with LSE atomics :)

Thanks,

        tglx