What 500,000 Benchmark Iterations Reveal About Linux RT-PREEMPT in Automotive Systems

WCET characterisation, outlier attribution, and what the results mean for SoC countermeasure specification

At 100 km/h, one metre elapses every 36 milliseconds. That is the physical budget inside which an ADAS perception pipeline must complete its worst-case execution — not its average-case, not its P99, but its absolute worst case under adversarial conditions. Every microsecond of OS scheduling jitter is engineering budget consumed. This is not an abstraction. It is why worst-case execution time (WCET) characterisation is a hard requirement, not an optimisation exercise.

The question facing automotive engineers is no longer whether Linux can be made real-time. RT-PREEMPT was mainlined into Linux 6.12 in 2023, removing the last barrier to upstream RT Linux for automotive applications. NVIDIA DriveOS Linux has achieved ASIL-B qualification in a production ADAS platform. The ELISA project is building systematic safety argumentation frameworks for Linux in safety-critical systems. The question engineers are actually asking is more specific: does Linux RT-PREEMPT meet the determinism and WCET requirements of their target application, under their specific mixed-criticality deployment conditions?

That question requires measurement, not specification reading. This article summarises what we found when we measured it systematically — and specifically, what we found when we looked beyond the headline numbers to ask why the outliers occur and what can be done about them.

The framework: what we measured and how

The benchmark framework targets five RTOS primitives most relevant to automotive timing chains: task switching latency (TSLat), intertask message latency (IMLat), mutex shuffling latency (MuLat), task preemption latency (PreLat), and interrupt handling latency (InLat). Each benchmark executes 500,000 iterations with measurement threads pinned to an isolated CPU core, evaluated across four stressor profiles simulating realistic mixed-criticality deployment: idle, balanced CPU/memory/IO load, IO-intensive, and interrupt storm.

The timing reference is the ARM Generic Timer (cntvct_el0) — fixed frequency, DVFS-independent, user-space accessible without syscall overhead, and synchronised across all cores. A post-processing methodology defers all tick-to-nanosecond conversion until after measurement is complete, eliminating the observer effect: on Cortex-A72, a 128-bit multiply-divide for tick conversion takes 20–30 ns — a non-negligible fraction of a 2.5 µs task switch — and placing it in the measurement hot path produces bimodal histograms with an anomalous near-zero population.

The measurement environment is fully normalised: CPU frequency fixed to maximum via cpufreq governor, all memory locked with mlockall() to eliminate runtime page fault jitter, CPU3 isolated via isolcpus and rcu_nocbs, RT throttling disabled (sched_rt_runtime_us = -1), and all non-benchmark IRQs steered away from the measurement core. One deliberate exclusion: nohz_full is omitted from the kernel command line because it introduces syscall overhead incompatible with context-switch benchmarking. The complete configuration must be applied simultaneously — any single omission can produce worst-case spikes two to three orders of magnitude above median.

Statistical reporting uses P99.9 as the primary WCET metric. Median latency is a misleading figure for safety certification — it describes typical behaviour, not worst-case behaviour. For ASIL-B temporal determinism evidence under ISO 26262, P99.9 and maximum values under adversarial stressor load are the only defensible metrics.

The headline results: competitive steady-state, heavy-tailed worst case

AGL-RT with Linux RT-PREEMPT kernel 6.12 on ARM Cortex-A72 delivers competitive steady-state latency across all five metrics. TSLat median 2.4–2.6 µs, IMLat thread-mode median 5.4 µs, MuLat median 3.8–5.0 µs, PreLat semaphore median 1.5 µs, and InLat idle median 7.1 µs all demonstrate genuine real-time performance. P99.9 across all five metrics remains below 57 µs under idle conditions — within automotive OS primitive overhead budgets for most ADAS timing chains.

The gap is in worst-case tail behaviour, not steady-state performance. Maximum values tell a different story: TSLat reaches 168 µs, IMLat process mode reaches 595 µs, MuLat reaches 170 µs, and InLat reaches 156 µs under stress. These represent two to three orders of magnitude above median — jitter ratios of 60–1,153× depending on the metric and stressor. Under ISO 26262, worst-case values of this magnitude constitute a temporal Freedom from Interference (FFI) violation when CPU isolation is not enforced.

The critical finding, however, is not the magnitude of the outliers. It is their cause.

The methodology that matters: root cause attribution

Publishing WCET numbers without attributing the mechanisms that produce them is of limited engineering value. The second phase of this work — root cause attribution using ARM PMU counter correlation and Linux kernel Ftrace instrumentation — is what turns measurement data into actionable engineering guidance.

The methodology runs in five steps:

Step 1 — Threshold Capture: Flag samples exceeding P99.9 as outlier candidates during the benchmark run.

Step 2 — PMU Snapshot: At each outlier event, capture ARM PMU counters: LLC_MISS, L1D_MISS, DTLB_WALK, BUS_ACCESS, CPU_CYCLES, MEM_ACCESS.

Step 3 — Correlation: Compute Spearman correlation between PMU counter delta and latency delta across all outlier windows.

Step 4 — Attribution: Dominant PMU counter or Ftrace event for each outlier cluster → root cause label.

Step 5 — SoC Input: Attribution drives countermeasure specification — cache partition sizing, TLB way count, QoS policy, GIC IPI routing.

The results show that the dominant interference mechanism is different for each of the five metrics — and critically, that the countermeasure landscape splits into two distinct categories: irreducible kernel paths and hardware-addressable interference channels.

Per-metric attribution: Root cause for each metric

The TSLat finding warrants particular attention. Ftrace analysis across 404,000 kernel trace events shows that 99.1% of task switching latency outliers co-occur with __schedule() execution — specifically a raw_spinlock acquisition path that RT-PREEMPT cannot preempt by design. All hardware interference channels were systematically tested and eliminated: L1D, LLC, TLB, and Branch PMU counters all showed less than 2× enrichment in outlier windows. The interference is not coming from hardware. It is coming from the kernel itself — from a path that exists in RT-PREEMPT by architectural necessity, not configuration oversight.

The practical implication is direct: for task switching latency and task preemption latency, no software configuration eliminates the worst-case bound. The irreducible kernel non-preemptibility path must be characterised, its WCET contribution understood, and the system’s safety case written to account for it — not to eliminate it.

For mutex shuffling and intertask message latency, the picture is more actionable. LLC eviction is a genuine and addressable interference channel. ARM MPAM, available on ARMv8.4 automotive SoCs including NVIDIA Orin and Qualcomm SA8775P, enables hardware-enforced cache partitioning that can bound the LLC interference path. Cache coloring achieves similar results on platforms without MPAM. These are not configuration heuristics — they are data-driven hardware countermeasures, backed by 32× PMU enrichment evidence.

For interrupt handling latency, GIC IPI routing configuration is the countermeasure. The IPI displacement mechanism is confirmed by 2.1–3.1× enrichment in outlier windows — tractable and well-understood.

What this means for AGL-RT viability

The answer to the motivating question — is Linux RT-PREEMPT ready for automotive safety-critical workloads — is conditionally yes, with a more nuanced set of conditions than a simple “enforce CPU isolation” recommendation conveys.

For metrics whose outliers originate in the kernel scheduling path (TSLat, PreLat): AGL-RT is viable, but the safety case must account for the irreducible non-preemptibility contribution. The 500,000-iteration empirical dataset provides the P99.9 evidence layer required by ISO 26262 Part 6 for ASIL-B temporal determinism argumentation. The bound exists and is characterised — that is what the certification argument needs.

For metrics whose outliers originate in hardware interference channels (MuLat, IMLat, InLat): AGL-RT is viable and the worst-case bound can be reduced further through countermeasure specification. The PMU attribution data directly feeds SoC cache partition sizing, TLB way count allocation, and GIC routing policy — decisions that can now be made on empirical evidence rather than engineering intuition.

The gap in AGL-RT is not in steady-state performance. It is in worst-case isolation — and the mechanisms producing that worst case are now attributable, per metric, to specific kernel paths and hardware interference channels. That attribution is what turns measurement data into a certification argument.

What comes next

Three extensions are planned. Virtualization benchmarking under Xen with AGL-RT as guest domain addresses the mixed-criticality SDV SoC use case directly — understanding how hypervisor scheduling overhead compounds with the kernel non-preemptibility contribution is the next important question. Extension to Zephyr RTOS will provide a second open-source data point and enable genuine cross-platform comparison using the same five-metric framework.

The open-source benchmark framework — POSIX-compliant, cross-platform, five metrics, fully configurable stressor profiles — will be released on GitHub under the Apache 2.0 licence. Any team evaluating AGL-RT, Zephyr, or any POSIX-compliant RTOS for mixed-criticality deployment can reproduce these results or extend the framework to their target platform.

This article distils findings from two presentations: “Is Linux RT-PREEMPT Ready for Automotive Safety-Critical Workloads? A Systematic Benchmark Evaluation,” presented at Embedded World 2026 (Session 2.3, Nuremberg) and “A Unified Benchmark Framework for AGL/POSIX-Compliant RTOS on ARM,” presented at the AGL All Member Meeting 2026 (Tokyo). The Ftrace attribution analysis was developed as part of the extended AGL work.

Full paper (Zenodo): https://doi.org/10.5281/zenodo.20967588 AGL 2026 slides (Zenodo): https://doi.org/10.5281/zenodo.20970757 Open-source benchmark framework: https://github.com/zlhk100

AutomotiveLinux #SDV #RTOS #ISO26262 #WCET #AGL #EmbeddedWorld2026 #MixedCriticality #FunctionalSafety #ARM #OpenSource