Run interrupt handlers as untrusted user processes — and still get hardware-grade latency. 15 cycles from interrupt assertion to the first handler instruction, whether the target process is running or asleep.
A microkernel isolates each component as an unprivileged process. That is where the trouble starts for interrupts: the handler belongs to the component, but kernel forwarding costs an order of magnitude more than a kernel-level interrupt. Putting the handler back into the kernel restores latency and throws the isolation away.
A user-level handler waits for the kernel to switch domains, save the context, and forward the interrupt. Measured: over 800 cycles.
UINTR-style delivery skips the kernel only while the target is already scheduled. When it is dormant, the slow path returns — a bimodal, unpredictable distribution.
The hardware activates the handler together with its protection domains. 15 cycles, independent of the current process, with the isolation still enforced by hardware.
The same interrupt, four delivery models. Watch where the time goes — and why DULI’s bar stops first.
Kernel path: two hardware stages, then five software stages in series. UINTR falls back to the same software chain when the target is dormant. DULI: three hardware stages, then the user handler. eBPF is a safe execution model — 3.27× native average execution — not a delivery mechanism.
Schematic timing, not drawn to cycle scale; the numbers on the right are the measured values.
DULI's delivery path contains no kernel code: the hardware identifies the domain, loads PMP and the budget, and banks the interrupted context. The other models are slow for structural reasons: kernel mediation serializes trap, save, schedule, domain switch and restore; UINTR removes those steps only while the target is already scheduled; the software path still saves context and, when the target is dormant, reprograms PMP.
| Scheme | target running | target dormant |
|---|---|---|
| Kernel-mediated | >800 | >800 |
| Software fast path | 80 | 120 |
| DULI · V5 | 15 | 15 |
Most user-level interrupt schemes optimize the average case. DULI targets the worst case: the handler runs at the same speed whether its process is the current one or has been switched out for hours.
| Variant | Area overhead | Latency (cycles) |
|---|---|---|
| Base | 0% | 5 |
| V1 | +23% | 37 |
| V2 | +27% | 29 |
| V3 | +48% | 17 |
| V4 | +51% | 14 |
| V5 | +66% | 11 |
The five variants resolve one bottleneck at a time: table lookup, context stacking, bus contention, and finally the IID lookup itself. The design-space page walks through all five with area, power and latency numbers.
PLC and servo drives need at least 20 kHz. DULI sustains up to ~300 kHz and keeps jitter below 5% at 100 kHz while an unrelated process interleaves.
A Modbus-RTU foreground at 2 Mbps and an image-recognition background: DULI loses under 17% FPS at 1 Mbps, where kernel forwarding collapses.
A malicious handler that reads foreign memory or loops forever is terminated by the same hardware that delivered it. Faults stay inside the component.