[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <YvqgwVzlM9vfb8Ko@worktop.programming.kicks-ass.net>
Date: Mon, 15 Aug 2022 21:38:41 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Hector Martin <marcan@...can.st>
Cc: Boqun Feng <boqun.feng@...il.com>, Will Deacon <will@...nel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Greg KH <gregkh@...uxfoundation.org>, jirislaby@...nel.org,
Marc Zyngier <maz@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Catalin Marinas <catalin.marinas@....com>,
Asahi Linux <asahi@...ts.linux.dev>,
Oliver Neukum <oneukum@...e.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: Debugging a TTY race condition on M1 (memory ordering dragons)
On Tue, Aug 16, 2022 at 04:15:00AM +0900, Hector Martin wrote:
> FWIW, I didn't actually use a full barrier in my patch. I just replaced
> the test_and_set_bit() with the underlying atomic op, sans early exit path.
That isn't quite true; you used atomic_long_fetch_or() which is used in
the generic implementation, but x86 would end up using "LOCK BTS" for
arch_test_and_set_bit(), while atomic_*fetch_or() ends up being a "LOCK
CMPXCHG" loop (which is significantly worse, performance wise).
That said; I don't have a nice solution that works well across the
various architectures.
(in one previous instance of this problem we ended up using a
cmpxchg_relaxed() coupled with an smp_mb__before_atomic(), but there is
no relaxed version of test_and_set_bit())
Powered by blists - more mailing lists