Re: Overhead of arm64 LSE per-CPU atomics?

[Catalin Marinas <catalin.marinas@arm.com>]

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).

> 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.

> 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). 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.

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.

-- 
Catalin