QFabric: Guarded Cross-Domain Task Recovery and Its Limits on a Linux-RTOS Board

arXiv:2611.01598v1 [cs.AR] 1 Nov 2026

QFabric: Guarded Cross-Domain Task Recovery and Its Limits on a Linux–RTOS Board Ayushman Bhattacharya

Anwesha Chakraborty

Pollinations AI ayushman.elixpo@gmail.com

Dept. CSE, JIS University anwesha.elixpo@gmail.com

actually help, and how a runtime should decide when a faster prediction is not sufficient permission to migrate. We study this question with QFabric, a deliberately narrow prototype on the Arduino UNO Q. A portable task declaration is compiled for both domains, profiled in each, and governed by an empirical contract. A recovery controller applies hysteresis to complete observation windows, admits a candidate only if semantic, capacity, and predicted-cost conditions hold, drains in-flight work at an epoch boundary, and commits the move only if post-switch probation confirms the contract; otherwise it rolls back. The central finding is a boundary, not a speedup. On this board every MCU invocation pays a fixed dispatch cost of about 19 ms, and because that invocation is issued and relayed by Linux processes, Linux interference degrades the MCU path more than the Linux path. Migration therefore never improves a contract in our measurements; QFabric’s guards earn their place by refusing the moves that a naive controller would make. An earlier artifact release [7] reported a 36.6% improvement from recovery; Section VI-F identifies the measurement defects behind that result and shows that it does not hold. Contributions. This paper makes four contributions. First, it presents a guarded recovery protocol that combines a bounded Index Terms—heterogeneous embedded systems, asymmetric wire ABI, effect-based semantic admission, quiescent epoch multiprocessing, Linux, RTOS, interconnect characterization, switching, and probation-based commit or rollback (Section IV). timing contracts, runtime adaptation Second, it characterizes the UNO Q Linux–MCU interconnect across payload size, concurrency, load, and frequency governor I. I NTRODUCTION (Section VII-A). Third, it reports a matched-load measurement Embedded platforms increasingly integrate two execution study of five workloads in both domains under three load environments on one board: a Linux application processor conditions and two caller policies, decomposing each call into for libraries, networking, and developer productivity, and a compute and residual dispatch cost (Section VII-B). Fourth, it real-time microcontroller for isolation and predictable execu- evaluates the controller’s decisions on a four-node chain and tion [1], [2]. A task that can run in either domain faces a shows through an ablation that hysteresis and probation prevent placement choice whose consequences extend beyond compute harmful migrations (Sections VII-C–VII-D). Positioning. Approaches to cross-domain placement differ time. Crossing the boundary adds serialization and transport, contention reshapes tail latency, and a move may be illegal for in when the assignment of software to execution resources is fixed, what triggers a reassignment, and whether a reassignment stateful or Linux-specific operations. A natural idea is to treat the microcontroller as a refuge: must prove its benefit before it is kept. Static mapping binds when a task’s timing degrades on Linux, move it to the real-time at design time [3]; asymmetric-multiprocessing frameworks domain. Classical heterogeneous scheduling maps task graphs and partitioning hypervisors bind at configuration time [2], statically from cost estimates [3]; feedback scheduling adapts [8], [9]; and feedback scheduling, mode-change protocols, and resources to measured error [4]; and runtime verification makes migration runtimes rebind at runtime but keep a move once it timing violations observable [5], [6]. What remains unclear on is made [4], [10], [11], [12]. QFabric rebinds at runtime only asymmetric Linux–RTOS boards is whether such a move can after an observed contract violation, and keeps a move only Abstract—Heterogeneous embedded boards pair a Linux application processor with a real-time microcontroller (MCU), which suggests moving a task between the two domains when its timing degrades. We present QFabric, a prototype that treats cross-domain placement as guarded recovery from a violated empirical soft real-time contract: a bounded task is compiled for both domains, monitored in windows with hysteresis, switched only after semantic and capacity admission at a quiescent epoch boundary, and committed or rolled back after probation. On an Arduino UNO Q (Cortex-A53 Linux and a Cortex-M33 running Zephyr), we characterize the stock Bridge RPC interconnect and measure five workloads in both domains under idle, CPU-load, and higher-priority SCHED_FIFO contention, with ordinary and real-time callers. Each MCU invocation costs about 19 ms of dispatch regardless of compute, the MCU runs the heaviest kernel 34× slower, and because every call traverses Linux userspace, Linux contention inflates the MCU path far more than the Linux path (p99 up to 400 ms versus 17.0 ms). Across 30 cells of a fournode chain, Linux meets every contract within 0.8% misses and QFabric correctly never migrates; a controller without hysteresis migrates in 7 cells, raising p95 by up to 177×, and probation rolls back 5 of those moves. On Linux-dispatched heterogeneous boards, migration therefore cannot isolate a task from Linux interference, and recovery guards matter chiefly by preventing harmful moves. This paper supersedes an earlier artifact release whose reported improvement arose from measurement defects that we identify. All source, raw traces, and generators are public.

For the MCU, R includes MessagePack encoding, the Linux router, the serial link, and the return path; for Linux it is the cost of a pipe round P trip to a persistent executor. A chain observation costs LG = v∈V Lv,d(v) , and the controller predicts it from profiled 95th percentiles: X bG (d) = C q.95 (v, d(v)). (2)

Linux userspace (Cortex-A53) Application chain and QTask call sites

Contract monitor and recovery controller pipe

dispatch

Linux executor (persistent process)

v∈V

This is a transparent heuristic, not a worst-case execution-time bound. Because each MCU sample already includes its round trip from Linux, no separate boundary term is added. For a window w of n invocations with outcomes oi and latencies Li , the observed miss rate against a deadline D is

Bridge router (MessagePack RPC)

serial link Microcontroller (Cortex-M33)

n

Zephyr executor

m bw =

Fig. 1. QFabric on the UNO Q. The controller, dispatcher, and Bridge router run in Linux userspace; each task has a native implementation in both domains.

after observing that it helped. Table I in Section III compares these approaches in detail. The rest of the paper is organized as follows. Section II describes the platform and system model, Section III reviews and compares related work, Section IV presents the design, Section V the implementation, Section VI the methodology, Section VII the results, and Section VIII discusses implications and threats to validity before Section IX concludes. II. BACKGROUND AND S YSTEM M ODEL A. Target platform

1X 1[oi ̸= ok ∨ Li > D] , n i=1

(3)

and the window violates the contract when m b w > ϵ. The contract is an empirical soft real-time objective. C. Research questions We ask: RQ1, what does the Linux–MCU interconnect cost, and how does that cost respond to payload, concurrency, load, and frequency policy? RQ2, under matched load conditions, how do the two domains compare per call, and where does the time go? RQ3, on a four-node chain, do contract violations arise, and does the controller decide correctly against deployable baselines and an oracle? RQ4, are hysteresis, admission, and probation necessary? RQ5, what does the mechanism itself cost? III. R ELATED W ORK

The Arduino UNO Q combines a quad-core Arm CortexA53 application processor running Debian Linux with an STM32U585 Cortex-M33 microcontroller running Zephyr [1]. Arduino’s Bridge stack exposes MessagePack remote procedure calls in both directions through a Linux-resident router process [13]. The arrangement resembles remote-processor systems built on remoteproc and rpmsg [14], [15], but we use the stock UNO Q stack rather than modifying the transport. Fig. 1 shows how QFabric sits on this platform: the policy, the dispatcher, and the Bridge router all execute in Linux userspace, so every MCU invocation begins and ends there. B. System model An application is a chain G = (V, E) of tasks. Each task v ∈ V may have a Linux implementation, an MCU implementation, or both, together with fixed-width request and response types, a numeric identifier, and an effect class. Only pure, bounded tasks are migration eligible. A placement assigns a domain d(v) ∈ {L, M} to every task. Every invocation is issued from Linux userspace, so the latency observed for task v in domain d decomposes into local compute and a residual that captures dispatch, transport, and scheduling delay: Lv,d = Cv,d + Rv,d .

(1)

We review five lines of work that bear on cross-domain recovery and compare representative systems in Table I. Its first three columns follow the dimensions introduced in Section I: binding time, trigger, and the unit of isolation; the remaining columns record whether a property is central to the cited work, not whether it could be added. A. Static and feedback-driven placement HEFT ranks a task graph and maps it to heterogeneous processors using estimated computation and communication costs [3]. It is the natural static reference but does not monitor deployed timing. Real-time scheduling theory provides admission and schedulability foundations [19], and feedback scheduling adjusts resource allocation from runtime error [4]; autonomic computing generalizes the monitor–analyze–plan– execute loop [20]. QFabric uses such a loop, but its actuator is a guarded change of execution domain. B. Timing contracts and runtime verification Runtime verification observes real-time behavior with bounded intrusion [5]. Stochastic contracts provide empirical runtime checks for component systems [6], while formal timing contracts and zone-based models support verification and synthesis [21], [22]. These works motivate our contract semantics; our focus is the operational protocol after a violation.

TABLE I C OMPARISON OF QFABRIC WITH RELATED WORK . “S EMANTIC GUARD ” MEANS EFFECT- OR STATE - BASED MIGRATION ELIGIBILITY; “ VERIFIED SWITCH ” MEANS AN OBSERVED POST- SWITCH CHECK DECIDES WHETHER THE MOVE IS KEPT. Work

Binding time Trigger

Isolation unit

Semantic guard

RT admission

HEFT [3] Feedback scheduling [4] Stochastic contracts [6] Mode changes [10], [16] RT task migration [17] CoMOS [11] YASMIN [12] Awkernel [18] Jailhouse / Bao [8], [9] OpenAMP / rpmsg [2], [15] QFabric

design time runtime runtime runtime runtime runtime runtime runtime configuration configuration runtime

processor resource share component task set core processor processor core partition core task

– – – – – – – – – – ✓

– model-specific – ✓ ✓ – – – – – ✓

cost model control error contract monitor mode or budget overrun resource management runtime system scheduler DAG scheduler – – contract violation

Verified switch Linux–RTOS board – – – – – – – – – – ✓

– – – – – – – – – ✓ ✓

mechanisms [31]. CoMOS provides processor-agnostic tasks Heterogeneous SoCs that pair application cores with real- and runtime migration across heterogeneous processors [11]; time cores are commonly run as asymmetric multiprocessing YASMIN supports functionally equivalent task implementations systems, with Linux managing a remote RTOS through and user-space real-time mapping on heterogeneous COTS remoteproc and rpmsg; OpenAMP standardizes these inter- platforms [12]; and Awkernel brings DAG scheduling into an actions [2] and has been evaluated on real-time embedded SoC RTOS evaluated on physical hardware [18]. QFabric differs platforms [23]. Measurements on Zynq UltraScale+ show that in its trigger (an observed empirical-contract violation), its inter-processor signaling can reach sub-microsecond latency guards (semantic eligibility and capacity admission), and its when shared memory is used directly instead of the OpenAMP insistence on post-switch verification. To the best of our search, stack [24]. An alternative to physically separate cores is a this combination on a physical Linux–RTOS boundary is new; static partitioning hypervisor such as Jailhouse [8] or Bao [9]; we claim no novelty for placement, profiling, feedback control, their real-time behavior and interference on Arm platforms or timing contracts individually. Our measurements also bound have been compared empirically [25], and hypervisor-based when the combination can help, which prior work on migration isolation has been combined with programmable-logic memory typically does not report. on heterogeneous MPSoCs [26]. In these approaches the IV. QFABRIC D ESIGN assignment of software to cores or partitions is fixed at Section II showed that every invocation, in either domain, configuration time. QFabric takes the Linux–RTOS split and begins in Linux userspace and that a predicted improvement is its transport as given, and changes only which side executes a only an estimate. QFabric’s design therefore treats a migration declared task after a contract violation. as a hypothesis: it is attempted only when the evidence and the guards allow it, and kept only when observation confirms D. Timing analysis and mixed criticality it. QFabric’s contracts are empirical soft real-time bounds, not WCET guarantees. Static and measurement-based WCET A. QTask declaration and bounded ABI analysis [27], and measurement-based probabilistic timing A QTask declaration is the single source for Linux and MCU analysis in particular [28], [29], give principled ways to artifacts. The generator accepts fixed-size scalars, records, and derive bounds from observed executions, under assumptions bounded arrays; it rejects pointers, dynamic arrays, recursive that our percentile thresholds do not establish. The mixed- types, unsupported effects, and messages larger than the 988criticality literature, started by Vestal’s model of tasks with byte payload budget. Versioned big-endian headers carry a several execution-time estimates of different assurance [16] magic value, message kind, task identifier, request identifier, and surveyed by Burns and Davis [30], also studies runtime payload length, and flags. Golden vectors are checked indeadaptation when a lower-assurance estimate is exceeded. pendently in Python, C++, and on the MCU, which turns That reaction is usually a criticality mode change, a well- serialization bounds and effect eligibility into auditable facts studied class of protocol [10]. QFabric’s recovery can be rather than conventions. read as a narrow, cross-domain instance of this pattern: a B. Contracts and admission violated empirical bound triggers a guarded, verified change Profiles exclude warm-up invocations and retain raw obserof placement, not a change of criticality mode, and we make vations; a minimum sample count marks an estimator valid. no claim of certifiable guarantees. The per-task deadline is fixed by rule before any replay, from E. Migration across heterogeneous processors the idle profiles of both domains with ordinary callers:   Real-time task migration has been studied for dynamic idle D = 1.25 max p99 (v, d) , DG = |V | D. resource management in many-core systems with feasibility d∈{L,M} 1 ms analysis [17], and Linux supplies deadline-aware scheduling (4) C. Asymmetric multiprocessing and partitioning

TABLE II E XPERIMENTAL SETUP

Stable k bad windows Violation hysteresis

No switch

reject A(v, d) holds

Admit candidate, drain, new epoch Eq. (8) holds

quiescent violation Probation

Commit

Configuration

Board Linux domain MCU domain Transport Workloads Samples per run Load conditions Caller policies Per-task deadline Claim class

Arduino UNO Q Cortex-A53, Debian, AArch64 STM32U585 Cortex-M33, Zephyr Bridge RPC / MessagePack add, CRC-32, FIR×{1, 64, 512} 2000 after 100 warm-up idle, CPU, RT contention SCHED_OTHER, SCHED_FIFO 50 24–58 ms, Eq. (4) Empirical soft real-time

Rollback

Fig. 2. Guarded recovery. Every terminal outcome returns the monitor to Stable.

Taking the slower domain makes the contract feasible for both alternatives at idle, so a violation reflects degradation rather than an infeasible target. A candidate MCU move must also leave utilization below a reserved headroom h: ′ UM = UM + rv q.95 (v, M) ≤ 1 − h,

(5)

where rv is the invocation rate. A switch is admissible only when A(v, d) = Emin ∧ Ssemantic ∧ Sadmission
bG (d) ≤ DG ∧ Scooldown , ∧ C

(6)

and the controller reports a stable rejection code for every failed conjunct. C. Guarded recovery protocol Fig. 2 shows the recovery state machine. With windows of n = 20 invocations and tolerance ϵ = 1%, analysis begins only after k consecutive violating windows: analyze ⇐⇒

Item

k−1 ^

m b w−j > ϵ,

k = 3.

(7)

j=0

MCU executor answers each request in a single Bridge call that returns both the result and the compute time measured with the Zephyr cycle counter, so no diagnostic calls fall on the measured path. Requests carry a 64-byte input block encoded in base64 (at most 96 characters), inside the 128-byte payload envelope that Section VII-A verifies; both executors share one decoder so that they perform identical work. Every result is checked against an independent Python reference. Instrumentation is layered. Reduced mode records core timing, full mode adds structured observations, and disabled mode measures the base call path. An optional kernel probe is evaluated separately and is not required for control. An LED-matrix status display has disabled, static, and 10/30/60Hz refresh profiles so that its cost is measured rather than assumed. All records carry schema versions, run identifiers, monotonic timestamps, outcomes, and mode metadata, and command-line audits cross-check source hashes, sample counts, derived deadlines, and reported numbers. VI. E VALUATION M ETHODOLOGY The evaluation asks whether the protocol of Section IV ever has a beneficial move to make on real hardware, and what it does when it does not. This section describes how we measured both domains under matched conditions so that the answer is not an artifact of the measurement.

If no candidate satisfies Eq. (6), placement is unchanged. Otherwise the dispatcher stops accepting work, waits until no invocation is in flight, increments a routing epoch, and changes the active domain. The move is committed only if the pooled miss rate over P = 6 probation windows meets the contract, commit ⇐⇒ m b prob ≤ ϵ, (8)

A. Testbed and workloads

The implementation comprises a Python controller and evidence pipeline, generated C++ ABI code, an AArch64 Linux executor, and Arduino/Zephyr sketches. The Linux executor is a persistent process that receives requests over a pipe and reports its own compute time with a monotonic clock. The

run. Idle applies no load. CPU load runs eight stress-ng CPU workers under SCHED_OTHER. RT contention runs four stress-ng workers at SCHED_FIFO priority 80 with a 50% duty cycle in 10-ms slices, modeling a co-located higherpriority real-time workload that tuning the measured task cannot

Table II summarizes the setup. All measurements use one UNO Q with its stock Bridge stack. The five workloads span a trivial task and a compute sweep: a signed 32-bit addition; a bitwise CRC-32 over the 64-byte block; and a 16-tap triangular Q15 FIR filter over 32 samples repeated 1, 64, or 512 times with a pass-dependent perturbation, written FIR×1, FIR×64, and is rolled back to the previous epoch and domain otherwise. and FIR×512. A prediction thus authorizes probation, never commitment. B. Load conditions and callers V. I MPLEMENTATION Three conditions are applied for the whole duration of a

TABLE III P OLICIES COMPARED ON THE FOUR - NODE CHAIN

Policy

Role

Ordinary Linux

All tasks in Linux, default scheduling All tasks in Linux, SCHED_FIFO caller All eligible tasks on the MCU Declared placement L, M, M, L Domain with lower idle p95 Guarded recovery, ordinary caller Guarded recovery, SCHED_FIFO caller Non-causal per-visit minimum

Tuned Linux MCU-first Manual expert QFabric static QFabric recovery QFabric recovery (tuned) Offline oracle

through Linux and is affected by the same load. The present evaluation removes both defects and fixes its deadline rule and replay protocol in the repository before any new data was collected. Under the corrected method the earlier improvement does not hold. The earlier release remains available unchanged for transparency. VII. R ESULTS We answer the research questions in the order of the argument: first what it costs to cross the boundary (RQ1), then whether migration can recover that cost per call (RQ2) or per chain (RQ3), and finally whether the guards matter (RQ4) and what they cost (RQ5). A. RQ1: Interconnect characterization

All cross-domain costs in QFabric originate from the Bridge RPC path between Linux and the MCU, so we characterized it before deriving any contract. Each point is the mean of three repetition-level percentiles over 1,000 Linux-observed round trips, recomputed from 108,000 raw samples with zero failures. C. Evidence classes Under the default schedutil governor, an idle zero-byte We keep three evidence classes separate. Direct measure- echo has a p50 of 7.74 ms and p95 of 8.85 ms, sustaining 127.2 ments are the per-call latencies above. Hardware scenarios sequential calls/s; at the largest demonstrated-safe payload, 128 exercise the real controller on the board and demonstrate bytes, p95 rises to 34.04 ms and the rate falls to 30.2 calls/s one committed switch and one rollback. Ordered trace replay (Fig. 3a); latency grows nearly linearly with payload size. A composes the measured traces into a four-node chain: each 256-byte probe caused sustained loss of MCU RPC service, task visit consumes the next sample of the relevant trace in so we make no claim beyond 128 bytes. Four stress-ng CPU workers lowered several medians measured order, which preserves autocorrelation and regime changes, and 500 chain observations are replayed per cell. but raised p95 by 5.5%–23.5% across Linux-initiated calls. Replay runs the protocol of Section IV exactly, including Pinning the performance governor did not remove this Eqs. (4)–(8). It permits paired comparison across policies but tail penalty (6.7%–42.9%); it changed echo p95 by −11.1% to −1.3% at idle and by −0.2% to +10.6% under load. is not equivalent to running a complete application. Frequency policy therefore does not explain the loaded tail. D. Baselines With concurrent 8-byte callers, aggregate throughput grows Table III lists the policies. The oracle chooses, for every task sublinearly from 96.75 to 257.31 calls/s (2.66×) at one to eight visit, the faster of the two domains’ next measured samples; it workers, while p95 rises from 10.27 to 29.80 ms (Fig. 3b). Load increased throughput by 1.8%–8.2% yet produced a 115.82-ms is a non-causal lower bound, not a competitor. outlier, so contracts must be derived from tails, not throughput E. Statistics or medians. Primary metrics are p95 latency and deadline-miss rate. For per-call p95 we report 95% confidence intervals from a circular B. RQ2: Matched-load per-call comparison Table IV and Fig. 4 compare the domains per call. At idle, an block bootstrap (2,000 resamples, block length 50), which respects the short-range autocorrelation of measured traces. All MCU addition takes 18.81 ms at p95 against 0.075 ms in Linux, tables, figures, and numbers in the text are generated from the a 251× gap. Table V decomposes the idle median with Eq. (1). raw traces by scripts in the artifact, which record input digests. The MCU residual stays near 19 ms for every workload, so dispatch, not compute, dominates the MCU path; and the MCU F. Relation to the earlier release computes FIR×512 34× more slowly than the Cortex-A53, so An earlier artifact release [7] included a manuscript whose heavier kernels widen the gap rather than closing it. flagship result was a 36.6% p95 reduction from recovery on Load changes the picture in an instructive way. CPU load a replayed chain under Linux load. Re-examination found raises the ordinary Linux p95 to a few milliseconds, which a two defects. First, its Linux executor was a new process SCHED_FIFO caller removes almost entirely (Table VI, tuned per invocation, so Linux latency was dominated by process Linux). Under RT contention, the Linux path keeps a p95 below creation: 8.05 ms p95 for an addition, against 0.075 ms with 2 ms with occasional stalls, while the MCU path degrades the persistent executor used here. Second, the replay drew sharply, with p99 up to 400 ms against 17.0 ms for Linux. MCU latencies from idle traces while drawing Linux latencies An MCU invocation traverses the caller, the Bridge router, from loaded traces, although every MCU call is dispatched and serial-driver activity, all on Linux, so it is exposed to the preempt. Under each condition both domains are profiled with an ordinary caller and with the caller and Linux executor at SCHED_FIFO priority 50, giving 12 profile runs and 120,000 retained invocations.

30 20

p95 latency (ms)

Round-trip latency (ms)

idle p95 loaded p95 idle p50 loaded p50

10 0

1

8 32 Payload (bytes)

8 4

20

4 2

10 0

0

8

idle loaded

30

128

1

2

1

100

150 200 250 Aggregate throughput (calls/s)

(b) 1/2/4/8 concurrent workers, 8-byte payload

(a) Payload sweep, one sequential caller

Fig. 3. Linux↔MCU Bridge RPC characterization under the schedutil governor. Values are means of three repetition-level percentiles; “loaded” runs four stress-ng CPU workers. Point labels in (b) give the worker count.

TABLE IV P ER - CALL P 95 LATENCY ( MS ) WITH ORDINARY CALLERS . B RACKETS GIVE 95% BLOCK - BOOTSTRAP CONFIDENCE INTERVALS . Load

Workload

Linux p95 [95% CI]

MCU p95 [95% CI]

Idle

add CRC-32 FIR×1 FIR×64 FIR×512

0.07 [0.07, 0.08] 0.15 [0.12, 0.16] 0.08 [0.08, 0.09] 0.45 [0.44, 0.46] 1.31 [1.22, 1.33]

18.81 [18.79, 18.84] 19.78 [19.76, 19.79] 20.16 [20.13, 20.19] 23.07 [23.00, 23.14] 45.93 [45.88, 46.02]

add CRC-32 FIR×1 FIR×64 FIR×512

0.18 [0.14, 0.23] 5.37 [5.22, 5.55] 5.13 [4.94, 5.41] 7.20 [6.56, 7.46] 9.24 [9.11, 9.39]

21.49 [21.16, 21.86] 23.17 [22.72, 23.35] 23.22 [22.80, 23.51] 27.42 [27.27, 27.75] 50.76 [50.31, 51.09]

add CRC-32 FIR×1 FIR×64 FIR×512

0.14 [0.10, 0.17] 0.24 [0.19, 0.27] 0.23 [0.17, 0.26] 0.76 [0.74, 0.78] 1.59 [1.54, 1.67]

39.99 [38.74, 42.70] 40.33 [38.48, 47.21] 42.04 [39.24, 44.47] 37.70 [36.36, 39.10] 200.37 [195.34, 219.40]

CPU

RT

TABLE V I DLE PER - CALL DECOMPOSITION (E Q . 1). C OMPUTE IS MEASURED INSIDE EACH EXECUTOR ; THE RESIDUAL IS THE DIFFERENCE OF MEDIANS . Compute p50 (µs)

Residual p50 (ms)

Workload

Linux

MCU

Linux

MCU

add CRC-32 FIR×1 FIR×64 FIR×512

0.1 1.3 1.7 95.7 760.4

0.8 26.9 52.4 3231.2 25842.1

0.053 0.060 0.060 0.277 0.380

18.53 19.09 19.27 18.85 19.12

co-runner at several points, whereas a Linux invocation needs one runnable core at one point. Moving a task to the MCU does not move its dispatch path off Linux. C. RQ3: Chain-level outcomes and controller decisions Table VI reports the replayed four-node chain. Linux meets the contract in every cell: the worst ordinary-Linux p95 is 26.7 ms against graph deadlines of at least 96 ms, and the worst miss rate of either Linux policy is 0.8%. MCU-first is several times slower in every cell. The offline oracle coincides with Linux except for rare visits in which a stalled Linux sample exceeds the paired MCU sample. With the hysteresis

TABLE VI R EPLAYED FOUR - NODE CHAIN , 500 OBSERVATIONS PER CELL ; LATENCIES IN MS . DG IS THE GRAPH DEADLINE OF E Q . (4). N EITHER QFABRIC RECOVERY VARIANT SWITCHED IN ANY CELL . Ordinary Linux

Tuned Linux

Load Workload DG

p95 miss (%)

p95 miss (%)

Idle

0.27 0.52 0.32 1.69 4.99

0.0 0.0 0.0 0.0 0.0

0.22 0.26 0.25 1.63 4.65

0.0 0.0 0.0 0.0 0.0

74.6 78.5 78.6 90.5 181.9

CPU add CRC-32 FIR×1 FIR×64 FIR×512

96 5.34 100 9.34 104 8.81 120 17.31 232 26.70

0.0 0.0 0.0 0.0 0.0

0.40 0.64 0.66 1.69 4.52

0.0 0.0 0.0 0.0 0.0

76.5 83.0 82.0 101.3 191.3

RT

96 0.58 100 0.85 104 0.81 120 3.97 232 20.07

0.2 0.31 0.2 0.56 0.2 0.71 0.8 2.97 0.0 17.00

0.0 0.0 0.2 0.2 0.8

444.5 458.9 452.8 253.6 539.3

add CRC-32 FIR×1 FIR×64 FIR×512

add CRC-32 FIR×1 FIR×64 FIR×512

96 100 104 120 232

MCU-first p95

of Eq. (7), QFabric performs 0 switches across all 30 cells, which is the correct decision: no admissible alternative would have improved the contract. D. RQ4: Are the guards necessary? Two kinds of evidence address the guards. On hardware, a controlled scenario detected a sustained violation one complete window after onset with no false switch, switched to a feasible alternate, and verified it after four windows; a separate injected scenario forced probation failure and produced a rollback. A negative suite exercised nine stable rejection reasons: insufficient evidence, unsatisfied contract, semantic ineligibility, destination admission failure, MCU headroom, predicted deadline miss, higher predicted end-to-end cost, observed miss-rate failure, and active cooldown. These scenarios demonstrate the protocol’s mechanics; their latencies are not used as performance evidence. Table VII isolates hysteresis on the Stage 12 traces by setting k = 1 in Eq. (7). The ablated controller reacts to isolated Linux stalls under RT contention and switches in 7 cells, raising p95 by up to 177× and increasing miss rates. Probation, Eq. (8),

Idle

CPU load

RT contention

p95 per call (ms)

3

10

Linux MCU 1

10

10−1 add

2

C-3 CR

×1

FIR

4

×6

FIR

12

add

×5

FIR

2

C-3

CR

×1

FIR

4

×6

FIR

12 ×5

add

FIR

2

C-3

CR

×1

FIR

4

×6

FIR

× FIR

512

Fig. 4. Per-call p95 latency with ordinary callers, logarithmic scale. Linux contention moves the MCU path more than the Linux path because each MCU call is issued and relayed by Linux processes.

TABLE VII H YSTERESIS ABLATION UNDER RT CONTENTION : SWITCHING ON THE FIRST VIOLATING WINDOW (k = 1) INSTEAD OF k = 3. Workload Caller add CRC-32 FIR×1 FIR×1 FIR×64 FIR×64 FIR×512

ordinary ordinary ordinary FIFO ordinary FIFO FIFO

Win.

p95 (ms)

Miss (%) Outcome

16 0.58→103.32 0.2→6.4 21 0.85→95.05 0.2→3.8 15 0.81→102.03 0.2→4.8 7 0.71→102.89 0.2→4.4 4 3.97→109.51 0.8→3.8 21 2.97→101.46 0.2→0.8 9 17.00→379.48 0.8→10.4

rolled back open at end rolled back rolled back rolled back open at end rolled back

TABLE VIII A NSWERS TO THE RESEARCH QUESTIONS

RQ

Answer

RQ1

About 9 ms p95 per zero-byte call, rising with payload; tails grow under load regardless of governor. Linux is faster in every cell; MCU dispatch is a fixed ≈19 ms and Linux contention hurts the MCU path more. No contract fails on Linux; QFabric correctly makes 0 switches in 30 cells. Yes: without hysteresis, 7 harmful switches; probation rolls back 5. A decision costs about 177.2 µs, negligible against dispatch.

RQ2 RQ3 RQ4 RQ5

rolls back 5 of these moves; the remaining two were still in probation when the trace ended (“open at end”). Hysteresis prevents the harmful moves, and probation bounds the damage when a move is made anyway. E. RQ5: Mechanism overhead The mechanism itself is inexpensive. One policy decision costs 170.1 µs of CPU time and 177.2 µs of wall time at p95 over 1,000 in-process evaluations, with a 3138-byte peak observed by tracemalloc; the latter excludes the interpreter baseline and is not total process memory. A decision is thus two orders of magnitude cheaper than one MCU dispatch (18.81 ms at p95 for an idle addition). The worst LED-matrix refresh profile changes Bridge p95 by 2.05%.

VIII. D ISCUSSION A. When can cross-domain recovery pay off? Equation (1) makes the boundary explicit. Migrating task v from Linux to the MCU helps only if Cv,M + Rv,M < Cv,L + Rv,L under the degraded condition. On this board Rv,M ≈ 19 ms at idle, Cv,M exceeds Cv,L by more than an order of magnitude, and the interference that inflates Rv,L inflates Rv,M at least as much, because both residuals are paid in Linux userspace. The inequality therefore fails for any task dispatched one call at a time from Linux. Three architectural changes could reverse it: a lower-latency transport such as shared-memory signaling, which reaches sub-microsecond latency on other heterogeneous SoCs [24]; a dispatcher outside Linux userspace, for example a kernel driver or a partitioned core [25]; or MCUresident chains whose release is triggered by an MCU timer so that only inputs and results cross the boundary. Each is a direct test of the boundary reported here. B. What the guards contribute Recovery and tuning solve different problems. When the workload can remain in Linux, a SCHED_FIFO caller removes most CPU-load interference and is the right first step. The value of QFabric’s guards is that they make adaptive placement safe to leave enabled: hysteresis ignores isolated stalls, admission rejects moves predicted to miss, and probation reverses moves whose benefit does not materialize. Table VII shows that a plausible but unguarded controller would have turned submillisecond tails into 100-ms tails. C. Programmer effort A task declaration states types, effect, and identifier once, and the generated ABI removes hand-written marshaling. The programmer must still supply semantically equivalent implementations for both domains, choose a defensible contract, and state Linux-only effects; QFabric shifts effort from transport plumbing to contracts and equivalence rather than removing it. D. Threats to validity External validity. Results come from one UNO Q, one software stack, and five small kernels. Boards with faster transports or dispatch outside Linux userspace may reverse

the inequality above. The chain results replay measured traces rather than running a full application. Construct validity. Percentiles and miss rates do not establish worst-case execution time or hard real-time guarantees, and the admission test of Eq. (5) is a utilization gate, not a schedulability proof. The residual in Table V is a difference of medians, not a measured component. Internal validity. All runs share one board and may be affected by firmware, thermal state, and background activity. Ordered replay preserves temporal structure within a trace but cannot represent interactions between tasks executing concurrently. The deadline rule and replay protocol were committed to the repository before any Stage 12 data was collected. Baseline and load validity. SCHED_FIFO is a strong but not exhaustive Linux baseline; SCHED_DEADLINE [31], CPU isolation, and affinity warrant comparison. The RT-contention co-runner is one synthetic pattern; synchronized or fully saturating interference would change magnitudes, though it would burden the MCU dispatch path as well. Safety scope. Quiescent switching prevents mixed-epoch calls in the prototype and effect annotations reject knownineligible tasks, but this is not a proof of implementation equivalence. Production use would need state transfer, authentication, fault containment, and multi-client analysis. IX. C ONCLUSION QFabric demonstrates a guarded form of runtime adaptation across a Linux–RTOS boundary: an empirical contract violation can trigger a quiescent, admitted switch whose benefit must be observed before it is kept. Measured on an Arduino UNO Q with matched load conditions, the Linux–MCU path costs about 19 ms per call, the MCU computes up to 34× more slowly, and Linux interference reaches the MCU path through its Linuxresident dispatch. Migration consequently never improves a contract in our study, the controller correctly declines to migrate, and an unguarded controller would have made harmful moves that only probation undoes. The broader lesson for heterogeneous embedded architectures is that the isolation offered by a real-time core is available only to work whose dispatch also leaves the general-purpose domain. Testing faster transports, non-Linux dispatch, and MCU-resident chains is the natural next step. A RTIFACT AVAILABILITY The repository [32] contains source, generated code, unit tests, board sketches, raw and processed traces, campaign logs, audits, and the generators for every number, table, and figure in this paper; running make in the paper directory regenerates the assets and builds the PDF. The release cited here, v1.1.0, is archived on Zenodo with DOI 10.5281/zenodo.23692354. R EFERENCES [1] Arduino, UNO Q User Manual, Arduino, 2026, accessed 2026-10-09. [Online]. Available: https://docs.arduino.cc/tutorials/uno-q/user-manual/

[2] OpenAMP Project, “The OpenAMP project,” Hosted by Linaro, 2026, accessed 2026-10-27. [Online]. Available: https://www.openampproject. org/ [3] H. Topcuoglu, S. Hariri, and M.-Y. Wu, “Performance-effective and low-complexity task scheduling for heterogeneous computing,” IEEE Transactions on Parallel and Distributed Systems, vol. 13, no. 3, pp. 260–274, 2002. [4] C. Lu, J. A. Stankovic, G. Tao, and S. H. Son, “Feedback control real-time scheduling: Framework, modeling, and algorithms,” Real-Time Systems, vol. 23, pp. 85–126, 2002. [5] T. Reinbacher, M. Függer, and J. Brauer, “Runtime verification of embedded real-time systems,” Formal Methods in System Design, vol. 44, pp. 203–239, 2014. [6] P. R. Nandi, A. Monot, and M. Oriol, “Stochastic contracts for runtime checking of component-based real-time systems,” in Proceedings of the 18th International ACM SIGSOFT Symposium on Component-Based Software Engineering, 2015, pp. 138–147. [7] A. Bhattacharya and A. Chakraborty, “QFabric: Contract-driven cross-domain task recovery,” GitHub release v1.0.1, 2026, earlier artifact release; its manuscript is superseded by this paper. [Online]. Available: https://github.com/elixpo/qfabric/releases/tag/v1.0.1 [8] R. Ramsauer, J. Kiszka, D. Lohmann, and W. Mauerer, “Look mum, no VM exits! (almost),” in Proceedings of the 13th Workshop on Operating Systems Platforms for Embedded Real-Time Applications (OSPERT), 2017. [9] J. Martins, A. Tavares, M. Solieri, M. Bertogna, and S. Pinto, “Bao: A lightweight static partitioning hypervisor for modern multi-core embedded systems,” in Next Generation Real-Time Embedded Systems, ser. OpenAccess Series in Informatics, vol. 77, 2020, pp. 3:1–3:14. [10] J. Real and A. Crespo, “Mode change protocols for real-time systems: A survey and a new proposal,” Real-Time Systems, vol. 26, no. 2, pp. 161–197, 2004. [11] M. Goraczko, C.-C. Han, J. Helander, J. Liu, B. Priyantha, and F. Zhao, “CoMOS: An operating system for heterogeneous multi-processor sensor devices,” Microsoft Research, Tech. Rep. MSR-TR-2006-177, 2006. [12] B. Rouxel, S. Altmeyer, and C. Grelck, “YASMIN: A real-time middleware for COTS heterogeneous platforms,” in Proceedings of the 22nd International Middleware Conference, 2021, pp. 298–309. [13] Arduino, Arduino RouterBridge Library, Arduino, 2026, accessed 2026-10-09. [Online]. Available: https://github.com/arduino-libraries/ Arduino_RouterBridge [14] Linux Kernel Developers, Remote Processor Framework, The Linux Kernel Documentation, 2026, accessed 2026-10-09. [Online]. Available: https://docs.kernel.org/staging/remoteproc.html [15] ——, Remote Processor Messaging (rpmsg) Framework, The Linux Kernel Documentation, 2024, accessed 2026-10-09. [Online]. Available: https://www.kernel.org/doc/html/v6.8/staging/rpmsg.html [16] S. Vestal, “Preemptive scheduling of multi-criticality systems with varying degrees of execution time assurance,” in Proceedings of the 28th IEEE International Real-Time Systems Symposium (RTSS), 2007, pp. 239–243. [17] B. Pourmohseni, A. Smirnov, S. Wildermann, and J. Teich, “Real-time task migration for dynamic resource management in many-core systems,” in Next Generation Real-Time Embedded Systems, ser. OpenAccess Series in Informatics, vol. 77, 2020, pp. 5:1–5:14. [18] A. Yano, R. Nishimura, Y. Kobayashi, Y. Takano, T. Ishikawa-Aso, and T. Azumi, “Awkernel: RTOS bridging DAG scheduling theory and component-oriented real-time systems practice,” 2026. [19] C. L. Liu and J. W. Layland, “Scheduling algorithms for multiprogramming in a hard-real-time environment,” Journal of the ACM, vol. 20, no. 1, pp. 46–61, 1973. [20] J. O. Kephart and D. M. Chess, “The vision of autonomic computing,” Computer, vol. 36, no. 1, pp. 41–50, 2003. [21] M. A. Khatib, A. Girard, and T. Dang, “Verification and synthesis of timing contracts for embedded controllers,” in Proceedings of the 19th International Conference on Hybrid Systems: Computation and Control, 2016. [22] M. Camilli, A. Gargantini, and P. Scandurra, “Zone-based formal specification and timing analysis of real-time self-adaptive systems,” Science of Computer Programming, vol. 159, pp. 28–57, 2018. [23] S. Alonso, J. Lazaro, J. Jimenez, L. Muguira, and U. Bidarte, “Evaluating the OpenAMP framework in real-time embedded SoC platforms,” in Proceedings of the 36th Conference on Design of Circuits and Integrated Systems (DCIS), 2021, pp. 1–6.

[24] N. Coppik, P. Becker, and M. Ritter, “Low-latency real-time applications on heterogeneous MPSoCs,” in Next Generation Real-Time Embedded Systems, ser. OpenAccess Series in Informatics, vol. 128, 2025, pp. 2:1–2:14. [25] J. Martins and S. Pinto, “Shedding light on static partitioning hypervisors for Arm-based mixed-criticality systems,” in Proceedings of the 29th IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS), 2023, pp. 40–53. [26] G. Gracioli, R. Tabish, R. Mancuso, R. Mirosanlou, R. Pellizzoni, and M. Caccamo, “Designing mixed criticality applications on modern heterogeneous MPSoC platforms,” in 31st Euromicro Conference on Real-Time Systems (ECRTS 2019), ser. Leibniz International Proceedings in Informatics, vol. 133, 2019, pp. 27:1–27:25. [27] R. Wilhelm, J. Engblom, A. Ermedahl, N. Holsti, S. Thesing, D. Whalley, G. Bernat, C. Ferdinand, R. Heckmann, T. Mitra, F. Mueller, I. Puaut, P. Puschner, J. Staschulat, and P. Stenström, “The worst-case executiontime problem—overview of methods and survey of tools,” ACM Transactions on Embedded Computing Systems, vol. 7, no. 3, pp. 1–53, 2008. [28] L. Cucu-Grosjean, L. Santinelli, M. Houston, C. Lo, T. Vardanega, L. Kosmidis, J. Abella, E. Mezzetti, E. Q. nones, and F. J. Cazorla, “Measurement-based probabilistic timing analysis for multi-path programs,” in Proceedings of the 24th Euromicro Conference on Real-Time Systems (ECRTS), 2012, pp. 91–101. [29] R. I. Davis and L. Cucu-Grosjean, “A survey of probabilistic timing analysis techniques for real-time systems,” Leibniz Transactions on Embedded Systems, vol. 6, no. 1, pp. 03:1–03:60, 2019. [30] A. Burns and R. I. Davis, “A survey of research into mixed criticality systems,” ACM Computing Surveys, vol. 50, no. 6, pp. 1–37, 2017. [31] J. Lelli, C. Scordino, L. Abeni, and D. Faggioli, “Deadline scheduling in the Linux kernel,” Software: Practice and Experience, vol. 46, no. 6, pp. 821–839, 2016. [32] A. Bhattacharya and A. Chakraborty, “QFabric: Guarded cross-domain task recovery on a Linux–RTOS board,” Zenodo, software release v1.1.0, 2026, source repository: https://github.com/elixpo/qfabric; Apache-2.0. [Online]. Available: https://doi.org/10.5281/zenodo.23692354

Related documents

• Q-Reflector: Learning GUI Action Reflection with Generated Conditions#1386336
• CVE-2026-98235#1236931
• CVE-2026-97602 — HIGH 7.8#1098320
• Folding Attention Biases into Keys Makes Compacted KV Caches Run on Standard Kernels#1467844
• Boundary and Interface Systems: Admissibility at the Point of Contact#709743