|
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)
Reviewed-by: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Changbin Du <changbin.du@gmail.com>
Assisted-by: opencode:DeepSeek-V4-Pro
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
