蘋果自研 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 策略優化，針對着工作負載中的實際痛點，實施了相當有效的工程設計，而不是刻意追求片面的性能指標。
感興趣的朋友，可移步至 Eclecticlight.co 網站查看 Howard Oakley 撰寫的這兩篇文章：
《Cores shouldn’t all be the same: M1 Macs do better》
《How M1 Macs feel faster than Intel models: it’s about QoS》