Re: Overhead of arm64 LSE per-CPU atomics?

[Willy Tarreau <w@1wt.eu>]

On Thu, Nov 06, 2025 at 01:53:04PM +0000, Catalin Marinas wrote:
> On Thu, Nov 06, 2025 at 08:44:39AM +0100, Willy Tarreau wrote:
> > Do you have pointers to some docs suggesting what instructions to use
> > when you prefer a near or far operation, like here with stadd vs ldadd ?
> 
> Unfortunately, the architecture spec does not make any distinction
> between far or near atomics, that's rather a microarchitecture and
> system implementation detail. Some of the information is hidden in
> specific CPU TRMs and the behaviour may differ between implementations.
> 
> I hope Arm will publish some docs/blogs to give some guidance to
> software folk (and other non-Arm Ltd microarchitects; it would be good
> if they are all aligned, though some may see this as their value-add).

Yes I can definitely understand that it's never easy to place the cursor
between how to help developers get the most of your arch and how to keep
competitors away.

> > Also does this mean that with LSE a pure store will always be far unless
> > prefetched ? Or should we trick stores using stadd mem,0 / ldadd mem,0
> > to hint a near vs far store for example ?
> 
> For the Arm Ltd implementations, _usually_ store-only atomics are
> executed far while those returning a value are near. But that's subject
> to implementation-defined configurations (e.g. IMP_CPUECTLR_EL1). Also
> the hardware may try to be smarter, e.g. detect contention and switch
> from one behaviour to another.

OK, thanks for the explanation. It makes sense and tends to match what
one could naturally expect.

> > I'm also wondering about CAS,
> > if there's a way to perform the usual load+CAS sequence exclusively using
> > far operations to avoid cache lines bouncing in contended environments,
> > because there are cases where a constant 50-60ns per CAS would be awesome,
> > or maybe even a CAS that remains far in case of failure or triggers the
> > prefetch of the line in case of success, for the typical
> > CAS(ptr, NULL, mine) used to try to own a shared resource.
> 
> Talking to other engineers in Arm, I learnt that the architecture even
> describes a way the programmer can hint at CAS loops. Instead of an LDR,
> use something (informally) called ICAS - a CAS where the Xs and Xt
> registers are the same (actual registers, not the value they contain).
> The in-memory value comparison with Xs either passes and the written
> value would be the same (imp def whether a write actually takes place)
> or fails (in theory, hw is allowed to write the same old value back).

This is super interesting, thanks for sharing!

> So
> while the value in Xs is less relevant, CAS will return the value in
> memory. The hardware detects the ICAS+CAS constructs and aims to make
> them faster.

I had already notice some x86 models being able to often succeed on the
second CAS attempt, and suspected that they'd force the L1 to hold the
line until the next attempt for this purpose. This could be roughly
similar.

> >From the C6.2.50 in the Arm ARM (the CAS description):
> 
>   For a CAS or CASA instruction, when <Ws> or <Xs> specifies the same
>   register as <Wt> or <Xt>, this signals to the memory system that an
>   additional subsequent CAS, CASA, CASAL, or CASL access to the
>   specified location is likely to occur in the near future. The memory
>   system can respond by taking actions that are expected to enable the
>   subsequent CAS, CASA, CASAL, or CASL access to succeed when it does
>   occur.
> 
> I guess something to add to Breno's microbenchmarks.

I think so as well. Many thanks again for sharing such precious info!

Willy