服務質量（QoS）調度優化讓M1 Mac體驗得到進一步提升
蘋果自研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 撰寫的這兩篇文章：