容量是設備在一段時間內擁有的某些資源（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曲線重疊。整個處理器的整體效能/功耗曲線應該是一條連續的線。 perf/W 曲線中的不連續性迫使調度程序和頻率調節器猜測工作負載需要什麼；為了防止卡頓，調度程序和頻率調節器會錯誤地為工作負載提供超出其所需的容量。這會導致消耗過多的電力，從而導致熱節流。
假設一個具有兩個 CPU 叢集的 SOC：
- 集群 1（小集群）的功耗為 100-300mW，在吞吐量基準測試中得分為 100-300，取決於時脈。
- 集群 2（大集群）的功耗在 1000 到 1600mW 之間，在相同的吞吐量基準中得分在 800 到 1200 之間，具體取決於時脈。
在這個基準測試中，分數越高速度越快。雖然不比更慢更理想，但更快==更大的功耗。
如果調度程序認為 UI 工作負載在該吞吐量基準上需要相當於 310 分，那麼避免卡頓的最佳選擇是以最低頻率運行大型集群，從而浪費大量電量。 （這取決於 cpuidle 行為和競爭空閒；具有連續 perf/W 曲線的 SOC 更容易優化。）
其次，使用CPU組。確保您已在內核和BoardConfig.mk中啟用了 cpuset。您也必須在裝置特定的init.rc中設定實際的 cpuset 分配。一些供應商在他們的 BSP 中禁用此功能，希望他們可以使用其他提示來影響調度程序行為；我們覺得這沒有道理。 cpuset 可用於確保 CPU 之間的負載平衡以反映使用者在裝置上實際執行的操作的方式完成。
ActivityManager 根據應用程式的相對重要性（頂部、前台、背景）將應用程式指派到不同的 cpuset，更重要的應用程式可以更多地存取 CPU 核心。這有助於確保前台和頂級應用程式的服務品質。
cpusets 對於同類 CPU 配置非常有用，但您不應在未啟用 cpusets 的情況下交付具有異質 CPU 配置的裝置。 Nexus 6P 是關於如何在異構 CPU 配置上使用 cpuset 的良好模型；使用它作為您自己的設備配置的基礎。
CPU 集還透過確保對效能不關鍵的後台執行緒永遠不會與大型 CPU 核心進行負載平衡來提供功耗優勢，因為它們可能會花費更多的功耗，而用戶卻無法感受到任何好處。這也有助於避免熱節流。雖然熱節流是容量問題，但熱節流時抖動的改善會對 UI 效能產生巨大影響。由於系統的運行速度將接近其渲染 60FPS 的能力，因此導致丟幀的抖動較少。