容量是設備在一段時間內擁有的某些資源（CPU、GPU 等）的總量。本頁介紹如何識別和解決與容量相關的卡頓問題。
州長反應遲緩
為了避免卡頓，CPU 頻率調節器需要能夠快速響應突發性工作負載。大多數 UI 應用程序都遵循相同的基本模式：
- 用戶正在閱讀屏幕。
- 用戶觸摸屏幕：點擊按鈕、滾動等。
- 屏幕滾動、更改活動或以某種方式響應輸入的動畫。
- 顯示新內容時系統停頓。
- 用戶返回閱讀屏幕。
Pixel 和 Nexus 設備實現了觸摸提升以修改 CPU 頻率調節器（和調度程序）在觸摸時的行為。為了避免緩慢上升到高時鐘頻率（這可能導致設備在觸摸時丟幀），觸摸提升通常會在 CPU 上設置一個頻率下限，以確保觸摸時有足夠的 CPU 容量可用。地板在觸摸後會持續一段時間（通常大約兩秒鐘）。
Pixel 還使用 Energy Aware Scheduling (EAS) 提供的 schedtune cgroup 作為額外的觸摸增強信號：頂級應用程序通過 schedtune 獲得額外的權重，以確保它們獲得足夠的 CPU 容量以快速運行。與配備 Kryo CPU 的 Pixel 相比，Nexus 5X 和 6P 在小型和大型 CPU 集群（分別為 A53 和 A57）之間的性能差距要大得多。我們發現，小 CPU 集群並不總是足以實現流暢的 UI 渲染，尤其是考慮到設備上的其他抖動源。
因此，在 Nexus 5X 和 6P 上，觸摸提升會修改調度程序的行為，以使前台應用程序更有可能轉移到大內核（這在概念上類似於 CPU 頻率的下限）。如果不更改調度程序以使前台應用程序更有可能移動到大型 CPU 集群，則前台應用程序可能沒有足夠的 CPU 容量來呈現，直到調度程序決定將線程負載平衡到大型 CPU 內核。通過在觸摸增強期間更改調度程序行為，UI 線程更有可能立即在大內核上運行並避免卡頓，同時不會強制其始終在大內核上運行，這可能會對功耗產生嚴重影響。
熱節流
當設備必須降低其整體熱輸出時會發生熱節流，通常通過降低 CPU、GPU 和 DRAM 時鐘來執行。不出所料，這通常會導致卡頓，因為系統可能不再能夠提供足夠的容量來在給定的時間片內進行渲染。避免熱節流的唯一方法是使用更少的功率。沒有很多方法可以做到這一點，但根據我們對過去 SOC 的經驗，我們對系統供應商有一些建議。
首先，在構建具有異構 CPU 架構的新 SOC 時，確保 CPU 集群的性能/W 曲線重疊。整個處理器的整體性能/W 曲線應該是一條連續的線。 perf/W 曲線中的不連續性迫使調度程序和頻率調節器猜測工作負載需要什麼；為防止卡頓，調度程序和頻率調節器在為工作負載提供超出其需要的容量方面犯了錯誤。這會導致消耗過多的功率，從而導致熱節流。
想像一個具有兩個 CPU 集群的假設 SOC：
- 集群 1 是小型集群，其功耗可在 100-300mW 之間，在吞吐量基準測試中得分 100-300，具體取決於時鐘。
- 集群 2 是大型集群，其功耗在 1000 到 1600mW 之間，在相同的吞吐量基準測試中得分在 800 到 1200 之間，具體取決於時鐘。
在這個基準測試中，分數越高越快。雖然不比更慢，更快==更大的功耗更可取。
如果調度程序認為 UI 工作負載在該吞吐量基准上需要相當於 310 的分數，那麼避免卡頓的最佳選擇是以最低頻率運行大型集群，從而浪費大量功率。 （這取決於 cpuidle 行為和空閒競賽；具有連續 perf/W 曲線的 SOC 更容易優化。）
第二，使用cpusets。確保您在內核和 BoardConfig.mk 中啟用了BoardConfig.mk 。您還必須在設備特定的init.rc中設置實際的 cpuset 分配。一些供應商在他們的 BSP 中禁用此功能，希望他們可以使用其他提示來影響調度程序的行為；我們覺得這沒有意義。 cpusets 有助於確保 CPU 之間的負載平衡以反映用戶在設備上實際執行的方式完成。
ActivityManager 根據這些應用程序的相對重要性（頂部、前台、後台）將應用程序分配到不同的 cpuset，更重要的應用程序獲得對 CPU 內核的更多訪問權限。這有助於確保前台和頂級應用程序的服務質量。
cpusets 在同構 CPU 配置上很有用，但您不應該在未啟用 cpuset 的情況下交付具有異構 CPU 配置的設備。 Nexus 6P 是如何在異構 CPU 配置上使用 cpuset 的一個很好的模型；將其用作您自己設備配置的基礎。
cpuset 還通過確保對性能不重要的後台線程永遠不會將負載平衡到大 CPU 內核來提供功率優勢，在那裡它們可以花費更多的功率而沒有任何用戶感知的好處。這也有助於避免熱節流。雖然熱節流是一個容量問題，但抖動改進會對熱節流時的 UI 性能產生巨大影響。由於系統將運行更接近其渲染 60FPS 的能力，因此導致丟幀所需的抖動更少。