Re: [PATCH v5] perf bench: Add atomic operations benchmark

[Namhyung Kim]

On Fri, Oct 16, 2026 at 03:55:52PM +0800, Changbin Du wrote:
> Add a new 'atomic' collection to perf bench for benchmarking
> atomic read-modify-write operations with multi-threaded
> contention testing. It provides two subcommands:
> 
>   - atomic cas: contended compare-and-swap operations
>     (__atomic_compare_exchange_n)
>   - atomic inc: contended fetch-add operations (__atomic_fetch_add)
> 
> Both support a configurable thread count and runtime to measure
> atomic contention effects.
> 
> Why this benchmark is needed:
> - Atomic read-modify-write operations are fundamental to lock-free
>   algorithms and data structures. Understanding their performance
>   characteristics under contention is critical for designing
>   high-performance concurrent applications.
> - The benchmark helps identify atomic operation latency and
>   scalability issues across different thread counts, revealing
>   contention patterns that are not visible in single-threaded tests.
> - Useful for evaluating atomic implementation quality on different
>   architectures and for regression testing after changes to atomic
>   primitives or memory ordering.
> 
> Measurement methodology:
> - By default two threads contend for the counter, enough to expose
>   the contention effect; use -t to scale the count.
> - Each thread starts a private timer (clock_gettime CLOCK_MONOTONIC)
>   after synchronizing on a pthread_barrier, ensuring all threads
>   begin simultaneously.
> - Each thread performs a hot loop of the selected atomic operation
>   (compare-and-swap or fetch-add) on a shared unsigned long counter
>   for a fixed runtime. It counts its own completed operations in a
>   local variable, and the loop runs in batches so the termination
>   flag is only polled between batches.
> - The main thread sleeps for the runtime and then sets the flag; the
>   throughput of a repeat is the total operation count divided by the
>   measured wall time (the max per-thread runtime).
> - The shared counter is cache-line aligned (64 bytes) to isolate
>   contention to the target cache line and avoid false sharing.
> - The per-thread operation counts of the last repeat show whether
>   any thread failed to make progress under contention.
> - The first repeat is excluded from statistics as a warmup phase
>   to avoid cache-cold effects.
> 
> Example usage:
>   $ perf bench atomic all
>   # Running atomic/cas benchmark...
>     Threads: 2, runtime: 2 sec, repeats: 10 (warmup: 1)
>     Avg throughput: 68,599,954 ops/sec (+- 0.13%)
>     Per-thread ops (last repeat):
>       fastest:  74,842,112 ops
>       slowest:  63,176,704 ops
>       avg:      69,009,408 ops
> 
>   # Running atomic/inc benchmark...
>     Threads: 2, runtime: 2 sec, repeats: 10 (warmup: 1)
>     Avg throughput: 128,428,772 ops/sec (+- 0.54%)
>     Per-thread ops (last repeat):
>       fastest:  146,230,272 ops
>       slowest:  112,825,344 ops
>       avg:      129,527,808 ops
> 
> Output fields explained:
> - Threads: number of contending threads
> - runtime: seconds each thread runs per repeat
> - repeats: number of test runs (first is warmup)
> - Avg throughput: mean aggregate ops/sec across repeats
> - +- %: relative standard error of the mean throughput across repeats
> - Per-thread ops: fastest/slowest/avg operations per thread in the
>   last repeat (shows scheduling imbalance and lack of progress)
> 
> Assisted-by: opencode:DeepSeek-V4-Pro
> Signed-off-by: Changbin Du <changbin.du@xxxxxxxxx>

Reviewed-by: Namhyung Kim <namhyung@xxxxxxxxxx>

Thanks,
Namhyung