From: Will Deacon <will@kernel.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Dev Jain <dev.jain@arm.com>, Jisheng Zhang <jszhang@kernel.org>,
Dennis Zhou <dennis@kernel.org>, Tejun Heo <tj@kernel.org>,
Christoph Lameter <cl@gentwo.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, maz@kernel.org
Subject: Re: [PATCH] arm64: remove HAVE_CMPXCHG_LOCAL
Date: Tue, 17 Feb 2026 15:00:22 +0000 [thread overview]
Message-ID: <aZSChrCVnoWSe7h0@willie-the-truck> (raw)
In-Reply-To: <aZRyzy0SJ8uF3K2J@arm.com>
On Tue, Feb 17, 2026 at 01:53:19PM +0000, Catalin Marinas wrote:
> On Mon, Feb 16, 2026 at 08:59:17PM +0530, Dev Jain wrote:
> > On 16/02/26 4:30 pm, Will Deacon wrote:
> > > On Sun, Feb 15, 2026 at 11:39:44AM +0800, Jisheng Zhang wrote:
> > >> It turns out the generic disable/enable irq this_cpu_cmpxchg
> > >> implementation is faster than LL/SC or lse implementation. Remove
> > >> HAVE_CMPXCHG_LOCAL for better performance on arm64.
> > >>
> > >> Tested on Quad 1.9GHZ CA55 platform:
> > >> average mod_node_page_state() cost decreases from 167ns to 103ns
> > >> the spawn (30 duration) benchmark in unixbench is improved
> > >> from 147494 lps to 150561 lps, improved by 2.1%
> > >>
> > >> Tested on Quad 2.1GHZ CA73 platform:
> > >> average mod_node_page_state() cost decreases from 113ns to 85ns
> > >> the spawn (30 duration) benchmark in unixbench is improved
> > >> from 209844 lps to 212581 lps, improved by 1.3%
> > >>
> > >> Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
> > >> ---
> > >> arch/arm64/Kconfig | 1 -
> > >> arch/arm64/include/asm/percpu.h | 24 ------------------------
> > >> 2 files changed, 25 deletions(-)
> > > That is _entirely_ dependent on the system, so this isn't the right
> > > approach. I also don't think it's something we particularly want to
> > > micro-optimise to accomodate systems that suck at atomics.
> >
> > Hi Will,
> >
> > As I mention in the other email, the suspect is not the atomics, but
> > preempt_disable(). On Apple M3, the regression reported in [1] resolves
> > by removing preempt_disable/enable in _pcp_protect_return. To prove
> > this another way, I disabled CONFIG_ARM64_HAS_LSE_ATOMICS and the
> > regression worsened, indicating that at least on Apple M3 the
> > atomics are faster.
>
> Then why don't we replace the preempt disabling with local_irq_save()
> in the arm64 code and still use the LSE atomics?
Even better, work on making preempt_disable() faster as it's used in many
other places. Of course, if people want to hack the .config, they could
also change the preemption mode...
Will
next prev parent reply other threads:[~2026-02-17 15:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-15 3:39 Jisheng Zhang
2026-02-16 10:59 ` Dev Jain
2026-02-16 11:00 ` Will Deacon
2026-02-16 15:29 ` Dev Jain
2026-02-17 13:53 ` Catalin Marinas
2026-02-17 15:00 ` Will Deacon [this message]
2026-02-17 16:48 ` Catalin Marinas
2026-02-18 4:01 ` K Prateek Nayak
2026-02-18 9:29 ` Catalin Marinas
2026-02-17 17:19 ` Christoph Lameter (Ampere)
2026-02-20 6:14 ` Jisheng Zhang
2026-02-18 22:07 ` Shakeel Butt
2026-02-20 6:20 ` Jisheng Zhang
2026-02-20 23:27 ` Shakeel Butt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aZSChrCVnoWSe7h0@willie-the-truck \
--to=will@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=cl@gentwo.org \
--cc=dennis@kernel.org \
--cc=dev.jain@arm.com \
--cc=jszhang@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=maz@kernel.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox