苹果自研 M1 CPU 在性能和效率上给人留下了深刻的印象，不过霍华德·奥克利（Howard Oakley）在对 M1 Mac 的服务质量（QoS）调度优化进行了深入的研究之后，发现它能够给终端设备用户带来体验方面的进一步提升。目前 M1 芯片已经在桌面、笔记本电脑和 2021 款 iPad Pro 平板电脑上得到了应用，但许多人不知道的是，它的可预见性和可靠性也有特殊加成。
更高的吞吐量，并不总是意味着更好的用户体验。
作为 Mac 原生应用程序 Cormorant、Spundle 和 Stibium 的开发者，Howard Oakley 试图找出为何 M1 Mac 感觉比 Intel Mac 更轻快的原因，结果发现这种体验的关键点在于 QoS 性能调度优化。
此前人们已经习惯了将“性能”等同于“吞吐量”，以为单位时间内完成的任务越多越好。然而在终端用户的实际感受上，这种刻板的衡量指标却不是总能得到完美的印证。
Howard Oakley 指出，用户通常注意的并不是吞吐量，而是等待时间。不是单位时间内可以完成的任务次数，而是完成单个任务所花费的时间。
举个最大吞吐量与用户满意度负相关的例子，2006 年前后，Linux 内核中引入了完全公平队列（cfqI / O）调度程序。
cfq 可以进行广泛的调节，在开箱即用的配置中，它可以通过对磁盘读写进行重新排序，来最大程度地提升吞吐量以减少查找，然后为所有活动进程提供循环服务。
遗憾的是，尽管 cfq 实际上确实可以最大程度地提升最大吞吐量，但是这样做却增加了任务等待时间，意味着中等负载的系统，也会让用户感到反应迟钝，结果引发了大量的投诉。
尽管 cfq 可以针对较低的延迟进行调整，但大多数不满意的用户还是宁愿用竞争性调度程序（比如 noop 或 deadline）彻底取代它。
即便这么做无法达成最大吞吐量，但单个延迟的减少，还是为台式机 / 交互型应用的使用者带来了更高的满意度。
在发现以牺牲等待时间为代价的次优最大化吞吐量之后，大多数 Linux 发行版都摆脱了 cfq 。
Red Hat 和 RHEL 7 在 2013 年放弃了 cfq，Ubuntu 也在 2014 年的 Trusty Tahr（14.04）版本中作出了跟进，直到 2019 年彻底弃用 cfq 。
于是当 Howard Oakley 注意到 M1 Mac 对设备体验赞不绝口之时，就开始深入研究 macOS 的本机任务调度策略，因为性能衡量并不总是与终端设备用户的实际速度体验画等号。
据悉，macOS 提供了四张直观的任务调度优先级，从低到高依次为后台（background）、实用程序（utility）、用户发起（userInitiated）、以及用户交互（userInteractive）。
此外还有第五个级别，在没有手动指定 QoS 级别时，其允许 macOS 默认自行确定任务的优先级。
有趣的是，无论你使用的是 M1 Mac 还是 Intel Mac，这五档优先级都是一样的。
不同的是，在英特尔八核至强 W 处理器上，如果系统处于空闲状态，则 macOS 将在所有八个内核中调度任何任务，而忽视更具体的 QoS 设置。
但在 M1 平台上，即使系统完全处于空闲状态，后台（background）优先级任务也只能在 M1 的四个高效 / 低功率 Icestorm 内核上运行，使得四个高性能的 Firestorm 内核处于空闲状态。
尽管这么做会让 Howard Oakley 在 M1 Mac 上实测较低优先级的任务时（压缩 10GB 测试文件）的系统速度逊于 Intel Mac，但在从“系统空闲”到“极度繁忙”的整个范围内，M1 Mac 的操作体验反而更加一致。
其它更高级别的 QoS 测试，也在 M1 Mac 上具有较 Intel Mac 更高的一致性。macOS 倾向于将较低优先级的任务挪至低功耗核心，以便高性能核心可以更快地响应用户发起（userInitiated）和用户交互（userInteractive）类任务。
综上所述，苹果针对 M1 Mac 的 QoS 策略优化，针对着工作负载中的实际痛点，实施了相当有效的工程设计，而不是刻意追求片面的性能指标。
（举报）
