服務質量（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 撰寫的這兩篇文章：

《Cores shouldn't all be the same: M1 Macs do better》《How M1 Macs feel faster than Intel models: it’s about QoS》