From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 798CF2475E3 for ; Tue, 17 Feb 2026 16:48:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771346936; cv=none; b=QEj9HOc+/Dso7BUl0VIcBcrkplCqnQbUQOw+cQ8Yk0D1TTgMC3dY2hYRT6AtV0kmv0o86MyKxEhRZ0GN+61zyJAMAebwhWpmhfsFZfoLsp3qeF3UXLCRU9aVIHc1VZQMoUJOqhLjdWwX2uzc6+ZmGWpV05x/Zw23L+oSC4Yd+9Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771346936; c=relaxed/simple; bh=TVYUbfo5qM7MHorbJtPr61ATAIIJPxDgARRio8gh9Vw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hWomrY23Ginhfc+KFsvaPQIwv1nuYiYGX+ceL+WU0ttxmv+OJE/V6WmXnNFaBk49xv7/2mKUB0p52LtpFK2ichvKyWlAzbGwdrofOwePzAHRYzPliPXqricjhSmhEmXN2cE47vbzFaQYL+/7lyUwQ/te5A4edWerLLURPCu1V2w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5F4101477; Tue, 17 Feb 2026 08:48:48 -0800 (PST) Received: from arm.com (arrakis.cambridge.arm.com [10.1.197.46]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C339F3F62B; Tue, 17 Feb 2026 08:48:52 -0800 (PST) Date: Tue, 17 Feb 2026 16:48:49 +0000 From: Catalin Marinas To: Will Deacon Cc: Dev Jain , Jisheng Zhang , Dennis Zhou , Tejun Heo , Christoph Lameter , 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 Message-ID: References: <20260215033944.16374-1-jszhang@kernel.org> <89606308-3c03-4dcf-a89d-479258b710e4@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue, Feb 17, 2026 at 03:00:22PM +0000, Will Deacon wrote: > 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% [...] > > > > 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. > > > > > > 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. Yes, that would be good. It's the preempt_enable_notrace() path that ends up calling preempt_schedule_notrace() -> __schedule() pretty much unconditionally. Not sure what would go wrong but some simple change like this (can be done at a higher in the preempt macros to even avoid getting here): diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 854984967fe2..d9a5d6438303 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -7119,7 +7119,7 @@ asmlinkage __visible void __sched notrace preempt_schedule_notrace(void) if (likely(!preemptible())) return; - do { + while (need_resched()) { /* * Because the function tracer can trace preempt_count_sub() * and it also uses preempt_enable/disable_notrace(), if @@ -7146,7 +7146,7 @@ asmlinkage __visible void __sched notrace preempt_schedule_notrace(void) preempt_latency_stop(1); preempt_enable_no_resched_notrace(); - } while (need_resched()); + } } EXPORT_SYMBOL_GPL(preempt_schedule_notrace); Of course, changing the preemption model solves this by making the macros no-ops but I assume people want to keep preemption on. -- Catalin