Re: [PATCH bpf-next v3 1/3] bpf, x86: Support fetching AND/OR/XOR atomics in arena

[Tejun Heo]

Hello, Puranjay.

On Fri, Sep 25, 2026 at 06:48:20AM -0700, Puranjay Mohan wrote:
> The first CMPXCHG compares against an unrelated value, so barring
> coincidence it always loses and the arena form executes at least two
> locked CMPXCHGs every time. A losing locked CMPXCHG is still a full
> read-modify-write, so this is a real steady-state cost rather than an
> occasional retry, which is why the non-arena lowering keeps its load.

I'd prefer the v1 lowering with the load and the second extable entry.
The extra locked CMPXCHG is the common case rather than a retry, so on
x86 the fetching insn ends up more expensive than the load + cmpxchg loop
that BPF programs hand-roll today, e.g. the cmask helpers in
tools/sched_ext/include/scx/cid.bpf.h which are being converted to the
fetching builtins. As is, we'd likely keep the loop on x86 and only use
the fetching atomics on the other archs, which defeats the purpose.
Andrea raised the same concern on the scx side:

  https://github.com/sched-ext/scx/pull/3839#pullrequestreview-5318408089

The second extable entry is some added complexity in the JIT but that's
paid once, while the extra CMPXCHG is paid on every operation.

Thanks.

--
tejun