把中断处理程序放进不受信任的用户进程，却仍然获得硬件级延迟： 从中断触发到处理程序第一条指令只需 15 个周期——无论目标进程正在运行， 还是早已休眠。
微内核把每个组件隔离为非特权进程，这正是现代安全嵌入式软件的基础。但对 中断处理程序来说，麻烦恰恰从这里开始：处理程序属于组件，可内核转发一次中断 的开销，比内核级中断高一个数量级。把处理程序搬回内核能恢复延迟，却丢掉了 隔离。
用户级处理程序必须等内核切换保护域、保存上下文、转发中断。实测超过 800 个周期。
UINTR 式方案只在目标进程已经被调度时跳过内核。目标休眠时仍要回到慢路径, 形成双峰、不可预测的延迟分布。
硬件把处理程序连同它的保护域一起激活。15 个周期，与当前进程无关， 隔离仍由硬件强制执行。
同一个中断，四种交付模型。注意时间花在哪里——以及为什么 DULI 的进度条最早停下。
内核路径：两个硬件阶段，随后是五个串行的软件阶段。UINTR 在目标休眠时回退到同一条软件链路。DULI：三个硬件阶段，随后进入用户处理程序。eBPF 是安全执行模型——平均执行时间是原生代码的 3.27 倍——不是中断交付机制。
动画为示意时序，不是按周期等比缩放；右侧周期数为实测值。
DULI 的交付路径上没有内核代码：硬件完成域识别、装入 PMP 与预算、备份被中断的 上下文。其它模型慢在结构上：内核路径把陷入、保存、调度、域切换、恢复串行化； UINTR 只在目标已被调度时省掉这些步骤；软件路径仍要保存上下文，目标休眠时还要 重新配置 PMP。
| 方案 | 目标运行中 | 目标已休眠 |
|---|---|---|
| 内核转发 | >800 | >800 |
| 纯软件快路径 | 80 | 120 |
| DULI · V5 | 15 | 15 |
大多数用户级中断方案优化的是平均情况。DULI 优化的是最坏情况：无论所属进程 正在运行，还是已经被换出很久，处理程序的激活速度完全一样。
| 变体 | 面积开销 | 延迟（周期） |
|---|---|---|
| Base | 0% | 5 |
| V1 | +23% | 37 |
| V2 | +27% | 29 |
| V3 | +48% | 17 |
| V4 | +51% | 14 |
| V5 | +66% | 11 |
五个变体逐个消除瓶颈：表查询、上下文压栈、总线竞争，最后是 IID 查询本身。 设计空间页给出全部五个变体的面积、功耗与延迟数据。
PLC 与伺服驱动至少需要 20 kHz。DULI 可稳定输出接近 300 kHz，并在另一个 进程持续穿插时把 100 kHz 的抖动保持在 5% 以下。
2 Mbps 的 Modbus-RTU 前台与图像识别后台共存：1 Mbps 时 DULI 的 FPS 损失 不到 17%，而内核转发方案已经崩溃。
读取他人内存或死循环的处理程序，会被交付它的同一套硬件终止。故障被 限制在组件内部。