Spurious wake‑up latency observed with AArch64 WFE timeout when event and timeout coincide

Answer

The ARM Architecture Reference Manual states that when an external event and a WFxT timeout become true in the same cycle, the wake‑up reason is implementation‑defined. No architectural priority is mandated, so the observed latency depends on how a particular core resolves the race.

Confirmed facts from the architecture

• The timeout value is programmed in generic‑timer ticks read from CNTVCT_EL0.
• The architecture does not specify the update granularity of CNTVCT relative to the core clock, nor the exact pipeline stage at which the WFxT comparator samples the timer.
• The 64‑bit CNTVCT wraps around correctly on overflow, but the comparator and event monitor may sample the counter at different points, creating a race window of a few cycles.
• To use WFxT the core must implement FEAT_WFxT (ID_AA64ISAR1_EL1.WFxT == 1) and the OS must have enabled it (e.g., CONFIG_ARM64_WFXT=y in Linux).

Likely explanation of the observed latency

Because the priority is implementation‑defined, each core may:

• Favor the external event, waking a few cycles before the nominal timeout expiry.
• Favor the timeout, waking a few cycles after the event becomes visible.
• Show data‑dependent variation due to internal pipelining, branch prediction, or power‑state changes.

The effective timeout resolution is therefore limited by the timer‑clock period; a single tick can represent multiple core cycles, introducing an uncertainty of ±1–2 ticks (or more if the timer clock is divided). The race window can add another 1–3 cycles of jitter.

Steps to measure the behaviour on a specific core

1. Verify support: Read ID_AA64ISAR1_EL1 and check the WFxT field; read CNTFRQ_EL0 to obtain the generic‑timer frequency in Hz.
2. Prepare a measurement loop:

       ISB
       WFET #<N>   // N = timeout in timer ticks
       ISB
       MRS <x0>, PMCCNTR_EL0   // capture wake‑up time
       

   Ensure an ISB before and after WFET to prevent speculative execution from affecting the counter.
3. Generate a simultaneous external event: Use a second core or a timer interrupt to execute SEV at a cycle‑accurate offset calculated from N and the timer frequency read in step 1.
4. Collect latency: Subtract the pre‑WFET PMCCNTR_EL0 value from the post‑value to obtain the elapsed core cycles. Repeat the experiment ≥10 000 times and build a histogram.
5. Control for frequency scaling: Pin the CPU to a fixed frequency (e.g., cpufreq-set -g performance) and disable idle‑state deep‑sleep if possible.

Missing diagnostic detail that could change the recommendation

If you have access to the core’s Technical Reference Manual or silicon errata that specifies the exact comparator sampling point for WFxT, please provide that information; it would allow a more precise prediction of the race window and could shift the measurement methodology (e.g., adjusting the SEV offset).