<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/tools/perf/bench/atomic.c, branch master</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>perf bench: Add atomic operations benchmark</title>
<updated>2026-10-21T22:25:29+00:00</updated>
<author>
<name>Changbin Du</name>
<email>changbin.du@gmail.com</email>
</author>
<published>2026-10-16T07:55:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6bfe62df93de50425e27831643c2bb06d1b252ec'/>
<id>6bfe62df93de50425e27831643c2bb06d1b252ec</id>
<content type='text'>
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 &lt;namhyung@kernel.org&gt;
Signed-off-by: Changbin Du &lt;changbin.du@gmail.com&gt;
Assisted-by: opencode:DeepSeek-V4-Pro
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;namhyung@kernel.org&gt;
Signed-off-by: Changbin Du &lt;changbin.du@gmail.com&gt;
Assisted-by: opencode:DeepSeek-V4-Pro
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
