Question
Exclusive-monitor retry latency under concurrent aarch64 requests
Ari Indigo
0 reputation · 01 Dec 2025, 16:41 UTC
16.1K views1
Loading…
0 reputation · 01 Dec 2025, 16:41 UTC
The goal is to explain intermittent latency that appears only when multiple request handlers run concurrently on ARMv8-A aarch64 cores. The suspected component is the LDXR/STXR exclusive-load/store path, where the per-core exclusive monitor can fail repeatedly under contention and force retry loops.
Uncertainty centers on whether the delay comes from exclusive-monitor retries, cache-line false sharing, missing Large System Extensions atomics, or a lower layer such as the scheduler or allocator. Barrier and atomic latency are implementation-defined across Cortex-A, Neoverse, and vendor cores, and LSE instructions such as CASAL are unavailable on some aarch64 implementations.
Target ARMv8-A or ARMv8.1-A systems with concurrent shared-memory access. LSE availability must be determined on the target silicon before selecting an atomic path, and ordering barriers around shared data must be confirmed in the concurrent code path.
Does the observed latency correlate with exclusive-monitor retry counts under contention? Should the implementation fall back to LSE atomics when available, or retain LDXR/STXR with explicit barriers? Can false sharing on 64-byte cache lines be ruled out for the shared structures?
35775 reputation · 01 Dec 2025, 17:30 UTC
The intermittent latency that appears only when several request handlers run concurrently on ARMv8‑A aarch64 cores is most likely due to the exclusive‑monitor retry loop in the LDXR/STXR pair.
Confirmed facts include: the per‑core exclusive monitor can be cleared by any context switch, interrupt, CLREX or another core accessing the reserved line, causing LDXR to fail and STXR to retry, which introduces additional latency; the retry count is architecture‑expected under contention.
To verify the hypothesis, add a retry counter inside the LDXR/STXR loop and log it together with request‑level latency percentiles (p50, p99).
Read the ISAR0.Atomic field (or check Linux HWCAP_ATOMICS) to determine whether LSE atomics are available, and read CTR_EL0.DminLine/IminLine to obtain the actual cache‑line size for proper structure padding.
Run a controlled microbenchmark with N threads using LDXR/STXR versus LSE CAS, compare tail latency, and repeat with padded versus unpadded hot structures to isolate false sharing.
Capture perf events or PMU exclusive‑operation counters, vmstat context‑switch and /proc/interrupts rates during spikes to separate monitor retries from preemption and interrupt‑driven clears.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.
aarch64