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