SystemResponsiveness 与 MMCSS：0、10、20 和 100 这些值分别有什么作用
本页内容
在 BoosterX 中，此参数以“SystemResponsiveness”设置的形式呈现。值 10 会改变 MMCSS 预留，但在已验证场景中未确立其相对于 20 的优势；100 会禁用 MMCSS。
SystemResponsiveness 并非安慰剂。它是 MMCSS 的一个参数，Windows 会在启动时对其进行规范化并应用。在所研究的 Windows 11 中，值 0 产生了相同的有效状态 20，而 10 改变了 MMCSS 状态，但在合成调度器测试中未显示出相对于 20 的优势。
值 100 禁用了 MMCSS。线程注册未执行，线程未获得优先级提升，合成调度 workload 的 p99 延迟相对于 20 上升了约 11-12 ms。这一结果并不意味着 Windows 整体变慢了 60%，也不能证明 FPS、input latency 或真实音频出现恶化。
BoosterX 相关设置
Section titled “BoosterX 相关设置”实用设置页面：“后台任务的 CPU 预留”。
待验证的论断
Section titled “ 待验证的论断”该研究验证了三个独立的论断：
0、10、20、100以及缺失值是否会改变启动后 MMCSS 的实际状态。- 在 CPU 满载情况下，
10是否在合成 MMCSS workload 的 p99 延迟上相对于20具有实际显著的优势。 - 禁用 MMCSS 时的结果是否可由已注册线程失去优先级提升来解释。
即便机制变化和合成指标得到确认，也不能证明对用户延迟、音频或游戏性能有影响。
- Windows 11 Pro 25H2 x64，build
26200.9168。 - VMware VM：4 vCPU，8 GB RAM，电源计划为 Balanced。
- 主要状态：缺失值、
0、10、20和100。 - 边界附加检查：
1、9、11、19、21、99、101和0xFFFFFFFF。 - 结果仅适用于一台虚拟机和一版 Windows 构建。
该构建由 Microsoft Support 的更新页面 KB5121003 确认。
Microsoft 的文档说明
Section titled “ Microsoft 的文档说明”Microsoft 将 MMCSS 描述为一种机制，它允许 time-sensitive multimedia workload 在不完全挤占较低优先级工作的情况下获得对 CPU 的优先访问。参数 SystemResponsiveness 存储在 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile 中。
在 MMCSS 文档 中指出：
- 非 10 的倍数的值会向下取整到最接近的十位；
- 低于 10 和高于 100 的值会被调整为 20；
- 值 100 会禁用 MMCSS；
Games、Audio、Playback及其他配置文件都是 MMCSS 任务。
应用程序通过 AvSetMmThreadCharacteristics 将当前线程与任务关联，通过 AvSetMmThreadPriority 更改相对优先级，并通过 AvRevertMmThreadCharacteristics 取消注册。
文档未规定缺失 Registry value 的行为。其下方结果仅是针对已验证构建的观察。
主要指标是在四个 vCPU 满载情况下，Games 配置文件中周期性工作启动延迟的 p99。一次独立运行对应一次单独启动 Windows 后的一个状态。每次运行内执行了 2500 个周期，但它们不被视为独立的重复。
对每个状态进行了两轮各 10 次启动的系列。状态顺序经过平衡，未剔除离群值。实际显著阈值预先设定为 1.784 ms。对于与状态 20 的差异，使用了配对 bootstrap 95% CI。
两个系列分别展示：在第二个系列中运行了一个额外的 validation-only ETW 会话，而第一个系列中没有。它不是主要指标的来源，但第二个区块噪声更大，因此将 20 次运行合并可能会掩盖数据的不均匀性。
单独的机制检查包括对 10、20、100 和缺失值各进行四次启动。同一线程在尝试 MMCSS 注册之前、之后以及 cleanup 之后被测量。检查了注册结果、Win32 thread priority 以及通过 ETW 得到的实际调度器优先级。全部 16 次主要运行均被接受；该系列中没有丢失的 ETW events 或 buffers。基础设施试点未纳入结果。
Windows 如何处理这些值
Section titled “Windows 如何处理这些值”| 写入值 | 启动后观察到的状态 | 结果 |
|---|---|---|
| 缺失 | MMCSS 已停止，注册未执行，API 返回 100 | 该构建的单独观察 |
0, 1, 9 |
API 返回 20，MMCSS 运行中 | 规范化为 20 |
10 |
API 返回 10，MMCSS 运行中 | 值被使用 |
11, 19 |
API 返回 10，MMCSS 运行中 | 向下取整 |
20 |
API 返回 20，MMCSS 运行中 | 值被使用 |
21 |
API 返回 20，MMCSS 运行中 | 向下取整 |
99 |
API 返回 90，MMCSS 运行中 | 向下取整 |
100 |
MMCSS 已停止，注册未执行 | 文档所述的禁用 |
101, 0xFFFFFFFF |
API 返回 20，MMCSS 运行中 | 规范化为 20 |
对于数值，映射与 Microsoft 文档一致。在缺失 value 时，数字 100 是在没有有效 MMCSS 注册的情况下返回的，因此它被列为 API fallback，而不是对运行中的 MMCSS 查询的结果。该构建中的禁用状态已通过服务和注册单独确认，但不能自动套用到其他 Windows 版本。
新状态的可靠应用在重启后被观察到。更改 Registry 并未改变当前启动中已打开的 MMCSS handle 或新进程的状态。失败的停止和启动服务尝试不被视为受支持的应用方式。
合成延迟的 p99
Section titled “合成延迟的 p99”正差异表示相对于 20 更高（即更差）的 p99 延迟。
与 20 的比较 |
系列 1，差异及 95% CI | 系列 2，差异及 95% CI | 结论 |
|---|---|---|---|
10 |
+0.625 ms [-1.111; +2.474] |
+0.975 ms [-3.579; +5.613] |
未确立优势；未证明等价 |
0 |
+1.267 ms [-0.014; +2.564] |
-1.902 ms [-4.681; +0.718] |
结果不确定且方向不一致 |
100 |
+10.812 ms [+8.787; +12.915] |
+12.074 ms [+9.669; +14.127] |
在合成 proxy 中具有实际显著的危害 |
| 缺失 | +11.640 ms [+9.690; +13.480] |
+12.494 ms [+9.303; +16.208] |
在合成 proxy 中具有实际显著的危害 |
10 在两个系列中均未显示出相对于 20 的实际显著优势。第二个系列的宽区间既容许有益也容许有害，因此该结果不能称为等价性的证明。
禁用 MMCSS 时发生了什么变化
Section titled “禁用 MMCSS 时发生了什么变化”| 状态 | 注册 | MMCSS 状态 | 单线程 Win32 priority | 单线程 ETW priority |
|---|---|---|---|---|
20 |
4/4 | 运行中 | 0 -> 10 -> 0 |
8 -> 18 -> 8 |
10 |
4/4 | 运行中 | 0 -> 10 -> 0 |
8 -> 18 -> 8 |
100 |
0/4 | 已停止 | 0 -> 0 -> 0 |
8 -> 8 -> 8 |
| 缺失 | 0/4 | 已停止 | 0 -> 0 -> 0 |
8 -> 8 -> 8 |
最后两列中的序列表示注册前、尝试注册后以及 cleanup 后的状态。Process priority class 未改变。
这直接确认了合成指标恶化的一个原因：在 MMCSS 禁用时，测试线程继续执行相同的工作，但未获得优先级提升。CPU quota 和其他资源核算规则的单独贡献未被隔离。
100 和缺失值在服务状态、注册结果和线程优先级上一致。这不能证明它们在所有内部和用户场景中完全等价。
已确认的内容
Section titled “ 已确认的内容”SystemResponsiveness会改变 Windows 启动后观察到的 MMCSS 状态。0不会产生有效状态 0，而是规范化为 20。10和20允许线程注册，并在该测试中产生相同的优先级转变。- 在所选 p99 指标上，未确立
10相对于20的实际显著优势。 100会禁用 MMCSS；在已验证构建中，缺失 value 时观察到相同状态。- 在 MMCSS 禁用时，测试线程未获得优先级提升，且合成 p99 延迟在两个系列中均恶化。
未确认的内容
Section titled “ 未确认的内容”10和20对所有 MMCSS workload 等价。10会提高 FPS、降低 input latency 或改善音频。100必然导致 audio glitches、失同步或特定游戏中的问题。- 缺失值的观察会在另一版 Windows 构建上重现。
- 所得到的毫秒数是物理 end-to-end latency。
- 虚拟机的结果可套用到物理 PC。
该研究在一台 VMware VM 和一版 Windows 构建上完成。合成配置文件 Games 制造了可控的 CPU 竞争，但未复现游戏引擎、音频驱动、真实 input pipeline 或 display scanout。
在第二个系列中，额外的 ETW 会话仅用于验证，但可能改变了整体噪声水平。因此两个系列未合并为一个评估。机制检查显示了优先级提升的丧失，但未分离 MMCSS quota 和 accounting policy 的可能贡献。
未测量物理音频测试、FPS、frametime、click-to-photon 和 input latency。目前尚无在另一台机器或构建上的独立重复。
不要使用 0 来设定“零预留”：Windows 会将其调整为 20。不要将 10 视为已被证明更好的通用值：在该 VM 中未确立其相对于 20 的优势。
不要使用 100，也不要为了“解除限制”而删除该值。在已验证环境中，这会禁用 MMCSS，使线程失去优先级提升，并明显恶化合成 p99 延迟。在没有单独的物理测试的情况下，不能将此结论转化为对 FPS 或音频的精确预测。
对于普通系统，安全的结论仅限于保持 Windows 的默认状态。只有在预先选定用户指标、进行重复配对测量并确认可回退的情况下，更改才有正当理由。
简要的用户建议和确切的注册表状态发布在 “SystemResponsiveness” 页面。
在每个实验阶段之后，VM 都会恢复到受保护的初始状态。控制启动确认了 Registry value 20、MMCSS 运行中、无活动跟踪以及测试进程已结束。检查后执行了再次回退，VM 保持关闭。
公开的一手来源
Section titled “ 公开的一手来源”- Multimedia Class Scheduler Service，Microsoft Learn - MMCSS 的用途、
SystemResponsiveness、取整以及值为 100 时禁用。 - AvSetMmThreadCharacteristicsW，Microsoft Learn - 将当前线程注册到 MMCSS 任务。
- AvSetMmThreadPriority，Microsoft Learn - 已注册线程的相对优先级。
- AvRevertMmThreadCharacteristics，Microsoft Learn - 结束线程注册。
- KB5121003，Microsoft Support - Windows 11 build
26200.9168。
公开来源和表述已核对：2026-08-25。
该研究及所用工具归 BoosterX 开发者所有，因此开发者对结果有直接利益。方法和适用范围已在上文描述，结论可通过公开数据和所列公开来源进行核验。产品中存在该参数未被用作证据；10 的不确定结果和禁用 MMCSS 的负面结果均未被筛选而保留。
BoosterX Wiki 是独立出版物，与 Microsoft Corporation 无关联、未获其授权、未受其赞助、也未获其认可。
- 2026-09-20: 利益冲突免责声明加强为完整表述，并说明研究与工具的归属。
- 2026-08-25: 首次发布；新增两个分开的 p99 系列、线程优先级检查、音频和游戏方面的边界，以及已确认的状态恢复。