服務質量（QoS）調度優化讓M1 Mac體驗得到進一步提升－Ken641228的部落格

更高的吞吐量，並不總是意味著更好的用戶體驗。

作為 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 內核處於空閑狀態。