Overhead of arm64 LSE per-CPU atomics?

Paul E. McKenney paulmck at kernel.org
Wed Nov 5 12:45:04 PST 2025


On Wed, Nov 05, 2025 at 08:17:25PM +0000, Catalin Marinas wrote:
> On Wed, Nov 05, 2025 at 11:47:07AM -0800, Paul E. McKenney wrote:
> > On Wed, Nov 05, 2025 at 07:16:42PM +0000, Catalin Marinas wrote:
> > > I think we should change the percpu atomics, it makes more sense to do
> > > them near, but I'll keep the others as they are. Planning to post a
> > > proper patch tomorrow and see if Will NAKs it ;) (I've been in meetings
> > > all day). Something like below but with more comments and a commit log:
> > 
> > I do like fixing this in the arm64 percpu atomics.  However, this gets
> > me assembler errors, perhaps because I am using an old version of gcc
> > or perhaps because I am still based off of v6.17-rc1:
> > 
> > 	/tmp/ccYlMkU1.s: Assembler messages:
> > 	/tmp/ccYlMkU1.s:9292: Error: invalid addressing mode at operand 2 -- `stadd x2,x4,[x0]'
> > 	/tmp/ccYlMkU1.s:9428: Error: invalid addressing mode at operand 2 -- `stadd x3,x6,[x1]'
> > 	/tmp/ccYlMkU1.s:9299: Error: attempt to move .org backwards
> > 	/tmp/ccYlMkU1.s:9435: Error: attempt to move .org backwards
> 
> Are you sure it is applied correctly? There shouldn't be any trace of
> stadd in asm/percpu.h.

Right in one, apologies!  And just for the record, it is a bad idea to
apply such a patch while rebasing and being in a C++ forward-progress
discussion.  :-/

This gets us to the usual good-case latency, in this case 8.333ns.

Tested-by: Paul E. McKenney <paulmck at kernel.org>

							Thanx, Paul



More information about the linux-arm-kernel mailing list