3、QNX Adaptive Partitioning：自适应分区原理、CPU预算与预算继承、内存与IO带宽保护

3.1 自适应分区到底解决了什么问题？

说实话，我第一次接触QNX的自适应分区（Adaptive Partitioning）时，第一反应是：这不就是Linux的cgroup吗？后来踩了坑才发现，完全不是一回事。

传统RTOS里，我们做资源隔离通常靠静态分区。每个分区拿固定的CPU时间片，比如分区A拿30%，分区B拿70%。这很安全，但有个致命问题——浪费。分区A闲着，分区B忙死，但B就是不能多用那30%。

自适应分区不一样。它允许空闲分区的预算被其他分区借用。但注意，这不是无条件的。系统会保证每个分区最终能拿回它承诺的份额。说白了，就是「你的还是你的，但暂时不用可以借给别人」。

我在一个ADAS项目中遇到过这种情况：感知模块平时只需要20%的CPU，但遇到暴雨天气，算法复杂度暴增，需要冲到60%。如果用静态分区，要么给感知模块预留60%造成浪费，要么它跑不满直接丢帧。自适应分区完美解决了这个矛盾。

3.2 自适应分区的原理

自适应分区的底层机制其实不复杂。每个分区有一个预算（Budget），单位是微秒。系统以时间片轮转的方式调度，但每个分区的时间片长度由它的预算和当前系统负载共同决定。

举个例子：

分区A：预算 50% （每100ms里保证50ms）
分区B：预算 30%
分区C：预算 20%

正常情况下，调度器按比例分配时间。但如果分区A只用掉了30%，剩下的20%就会自动释放到「空闲池」里。分区B和C可以竞争这个空闲池。谁需要谁拿去用。

嗯，这里要注意：空闲池的分配不是先到先得。QNX用的是比例公平调度。也就是说，即使有空闲资源，系统也会尽量维持分区之间的相对比例。不会出现分区B突然吃掉所有空闲，导致分区C饿死的情况。

我个人习惯把自适应分区理解成一个「弹性容器」。每个容器有硬下限（保证的预算），也有软上限（可以借用的资源）。硬下限是安全底线，软上限是性能弹性。

3.3 CPU预算与预算继承

预算继承（Budget Inheritance）这个概念，我第一次看文档时绕了半天。后来在调试一个多线程死锁问题时才真正搞明白。

先看一个典型场景：

• 分区A里的线程T1持有锁L
• 分区B里的线程T2等待锁L
• T2在等待期间消耗的是分区B的预算

问题来了：T1什么时候释放锁？取决于T1能不能拿到CPU时间。如果分区A的预算用完了，T1被挂起，那T2就永远等不到锁。这就是优先级反转的变种——预算反转。

预算继承的机制就是解决这个问题的。当T2因为等待T1而阻塞时，T1会临时继承T2所在分区的预算。这样T1就能继续运行，尽快释放锁。

配置预算继承的API很简单：

// 创建一个分区
partition_handle = PartitionCreate("sensor_fusion", 50000); // 50ms预算

// 创建线程时指定分区
ThreadCreate(partition_handle, thread_func, NULL, NULL);

// 关闭预算继承（谨慎使用）
ThreadCtl(_NTO_TCTL_ADAPTIVE, &disable_inherit);

3.4 内存保护：不只是MPU的事

很多人以为QNX的内存保护就是靠MMU/MPU做地址隔离。其实自适应分区在内存方面也有自己的保护机制。

每个分区可以设置内存上限。比如分区A最多用256MB物理内存，分区B最多用128MB。一旦超过，系统会触发OOM处理策略——你可以选择杀掉超限进程，或者让它等待。

我曾经在一个项目中犯过错误：只配了CPU预算，没配内存上限。结果一个分区内存泄漏，把整个系统的内存吃光了，其他分区直接OOM崩溃。从那以后，我每个分区必配内存上限。

资源类型	保护方式	配置示例
物理内存	分区内存上限	PartitionMemoryLimit(handle, 256*1024*1024)
虚拟内存	地址空间隔离（MMU）	进程级自动隔离
共享内存	显式权限控制	shm_ctl() 设置访问权限

3.5 IO带宽保护：容易被忽视的坑

CPU和内存都保护了，IO呢？很多开发者会忽略这一点。你想想看，一个分区疯狂写日志，把磁盘带宽占满，其他分区的IO请求全被堵住——这跟CPU被抢光是一个效果。

QNX的自适应分区支持IO带宽限制。主要针对块设备（比如eMMC、NVMe）和网络接口。

配置方式：

// 限制分区A的磁盘IO带宽为50MB/s
io_limit_t io_limit;
io_limit.bandwidth = 50 * 1024 * 1024; // 50 MB/s
io_limit.burst_size = 1024 * 1024;     // 突发大小 1MB
PartitionIOLimit(handle, &io_limit);

这里有个细节：突发大小（burst_size）。它允许分区在短时间内超过带宽限制，但长期平均会被控制在设定值内。这个参数对实时性很重要——有些传感器数据需要短时间爆发写入，但平均带宽并不高。

我在一个车载信息娱乐系统中遇到过IO抖动问题。导航分区和媒体分区共享同一个eMMC。导航需要稳定的IO延迟来读取地图数据，但媒体分区在播放高清视频时IO压力很大。加了IO带宽限制后，导航的IO延迟从平均15ms降到了3ms以内。

3.6 实战建议：如何配置自适应分区

说了这么多原理，最后给点实战建议。我个人总结了一套配置流程：

1. 先做静态分析：每个模块的峰值CPU、内存、IO需求是多少？这是预算的下限。
2. 留出安全余量：预算不要卡得太死。我一般留20%的余量给突发情况。
3. 从大到小配置：先配CPU预算，再配内存上限，最后配IO带宽。别一上来全配，出了问题不好排查。
4. 压力测试验证：用stress工具模拟极端负载，观察分区之间是否互相影响。
5. 监控告警：生产环境中一定要监控每个分区的资源使用率。接近上限时提前告警。

好了，这一章的内容就到这里。下一章我们会讲QNX的安全启动链和可信执行环境，那是另一个有意思的话题。