intel_pstate CPU 效能調節驅動¶
- 版權所有:
© 2017 Intel Corporation
- 作者:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
常規資訊¶
intel_pstate 是 Linux 核心中 CPU 效能調節子系統 (CPUFreq) 的一部分。它是用於 Sandy Bridge 及以後幾代 Intel 處理器的調節驅動程式。但是，請注意，某些處理器可能不受支援。[要了解 intel_pstate，必須瞭解 CPUFreq 的一般工作原理，因此如果您尚未閱讀 CPU 效能調節，現在是時候閱讀了。]
對於 intel_pstate 支援的處理器，P-state 的概念比僅操作頻率或操作效能點更廣泛（有關更多資訊，請參見 Kristen Accardi 在 2015 年歐洲 LinuxCon 上的簡報 [1]）。因此，intel_pstate 在內部使用的 P-state 表示形式遵循硬體規範（有關詳細資訊，請參閱 Intel 軟體開發人員手冊 [2]）。但是，CPUFreq 核心使用頻率來標識 CPU 的操作效能點，並且頻率涉及它公開的使用者空間介面，因此 intel_pstate 也將其 P-state 的內部表示形式對映到頻率（幸運的是，該對映是明確的）。同時，對於 intel_pstate 來說，由於其可能的大小，向 CPUFreq 核心提供可用頻率表是不切實際的，因此驅動程式不這樣做。核心的某些功能受到限制。
由於 intel_pstate 使用的硬體 P-state 選擇介面在邏輯 CPU 級別可用，因此驅動程式始終與單個 CPU 一起工作。因此，如果正在使用 intel_pstate，則每個 CPUFreq 策略物件都對應於一個邏輯 CPU，並且 CPUFreq 策略實際上等效於 CPU。特別是，這意味著每次相應的 CPU 離線時它們都會變為“非活動狀態”，並且需要在返回線上狀態時重新初始化。
intel_pstate 不是模組化的，因此無法解除安裝，這意味著將早期配置時間引數傳遞給它的唯一方法是透過核心命令列。但是，可以透過 sysfs 在很大程度上調整其配置。在某些配置中，甚至可以透過 sysfs 登出它，這允許載入和註冊另一個 CPUFreq 調節驅動程式（請參見 below）。
操作模式¶
intel_pstate 可以在兩種不同的模式下執行，即主動模式或被動模式。在主動模式下，它使用自己的內部效能調節調控器演算法或允許硬體自行進行效能調節，而在被動模式下，它響應由通用 CPUFreq 調控器發出的請求，該調控器實現某種效能調節演算法。哪種模式生效取決於使用了哪些核心命令列選項以及處理器的功能。
主動模式¶
對於具有硬體管理的 P-state (HWP) 支援的處理器，這是 intel_pstate 的預設操作模式。如果它在此模式下工作，則 sysfs 中所有 CPUFreq 策略的 scaling_driver 策略屬性包含字串“intel_pstate”。
在此模式下，驅動程式繞過 CPUFreq 的調節調控器層，並提供其自己的調節演算法來選擇 P-state。這些演算法可以像通用調節調控器一樣應用於 CPUFreq 策略（即，透過 sysfs 中的 scaling_governor 策略屬性）。[請注意，可能會為不同的策略選擇不同的 P-state 選擇演算法，但不建議這樣做。]
它們不是通用調節調控器，但是它們的名稱與某些調控器的名稱相同。此外，令人困惑的是，它們通常與它們共享名稱的通用調控器的工作方式不同。例如，intel_pstate 提供的 powersave P-state 選擇演算法不是通用 powersave 調控器的對應項（大致，它對應於 schedutil 和 ondemand 調控器）。
intel_pstate 在主動模式下提供兩種 P-state 選擇演算法：powersave 和 performance。它們的操作方式取決於處理器中是否已啟用硬體管理的 P-state (HWP) 功能，並且可能取決於處理器型號。
預設使用哪種 P-state 選擇演算法取決於 CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE 核心配置選項。也就是說，如果設定了該選項，則預設情況下將使用 performance 演算法，如果未設定該選項，則預設情況下將使用另一個演算法。
具有 HWP 的主動模式¶
如果處理器支援 HWP 功能，則將在處理器初始化期間啟用該功能，並且之後無法停用該功能。可以透過在命令列中將 intel_pstate=no_hwp 引數傳遞給核心來避免啟用該功能。
如果已啟用 HWP 功能，則 intel_pstate 依賴於處理器自行選擇 P-state，但它仍然可以向處理器的內部 P-state 選擇邏輯提供提示。這些提示是什麼取決於已應用於給定策略（或其對應的 CPU）的 P-state 選擇演算法。
即使 P-state 選擇由處理器自動執行，intel_pstate 在此模式下也會向 CPU 排程程式註冊利用率更新回撥。但是，它們不用於執行 P-state 選擇演算法，而是用於定期更新當前 CPU 頻率資訊，以便從 sysfs 中的 scaling_cur_freq 策略屬性獲得。
HWP + performance¶
在此配置中，intel_pstate 將 0 寫入處理器的能耗效能偏好 (EPP) 旋鈕（如果支援）或其能耗效能偏差 (EPB) 旋鈕（否則），這意味著處理器的內部 P-state 選擇邏輯應完全專注於效能。
這將覆蓋來自 sysfs 介面的 EPP/EPB 設定（請參見下面的 能耗與效能提示）。此外，在此配置中，任何嘗試透過 sysfs 將 EPP/EPB 更改為與 0（“效能”）不同的值的嘗試都將被拒絕。
此外，在此配置中，處理器內部 P-state 選擇邏輯可用的 P-state 範圍始終限制為上限（即，驅動程式允許使用的最大 P-state）。
HWP + powersave¶
在此配置中，intel_pstate 會將處理器的能耗效能偏好 (EPP) 旋鈕（如果支援）或其能耗效能偏差 (EPB) 旋鈕（否則）設定為先前透過 sysfs 設定的任何值（或者平臺韌體設定的任何預設值）。這通常會導致處理器的內部 P-state 選擇邏輯對效能的關注較少。
沒有 HWP 的主動模式¶
對於不支援 HWP 功能的處理器，或者在命令列中將 intel_pstate=no_hwp 引數傳遞給核心時，此操作模式是可選的。如果在命令列中將 intel_pstate=active 引數傳遞給核心，則在這些情況下使用主動模式。 [請注意，intel_pstate 永遠不會拒絕使用任何啟用了 HWP 功能的處理器。]
在此模式下，intel_pstate 向 CPU 排程程式註冊利用率更新回撥，以便執行 P-state 選擇演算法，即 powersave 或 performance，具體取決於 sysfs 中的 scaling_governor 策略設定。這些利用率更新回撥也會定期更新當前 CPU 頻率資訊，以便從 sysfs 中的 scaling_cur_freq 策略屬性獲得。
performance¶
如果沒有 HWP，則無論處理器型號和平臺配置如何，此 P-state 選擇演算法始終相同。
每次更新給定 CPU 的驅動程式配置時（例如，透過 sysfs），它都會選擇允許使用的最大 P-state，但要受到透過 sysfs 設定的限制。
如果設定了 CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE 核心配置選項，則這是預設的 P-state 選擇演算法。
powersave¶
如果沒有 HWP，則此 P-state 選擇演算法類似於通用 schedutil 調節調控器實現的演算法，不同之處在於它使用的利用率指標基於來自 CPU 反饋暫存器的數字。通常，它選擇與當前 CPU 利用率成比例的 P-state。
當 CPU 排程程式呼叫給定 CPU 的驅動程式的利用率更新回撥時，會執行此演算法，但頻率不高於每 10 毫秒一次。與 performance 情況一樣，如果新的 P-state 與當前 P-state 相同，則不會觸及硬體配置。
如果未設定 CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE 核心配置選項，則這是預設的 P-state 選擇演算法。
被動模式¶
對於沒有硬體管理的 P-state (HWP) 支援的處理器，這是 intel_pstate 的預設操作模式。如果將 intel_pstate=passive 引數傳遞給核心，則始終使用它，而不管給定的處理器是否支援 HWP。 [請注意，如果 intel_pstate=no_hwp 設定未與 intel_pstate=active 結合使用，則會導致驅動程式在被動模式下啟動。] 與沒有 HWP 支援的主動模式一樣，在此模式下，如果透過核心命令列阻止啟用 HWP，則 intel_pstate 可能會拒絕使用其無法識別的處理器。
如果驅動程式在此模式下工作，則 sysfs 中所有 CPUFreq 策略的 scaling_driver 策略屬性都包含字串“intel_cpufreq”。然後，驅動程式的行為類似於常規 CPUFreq 調節驅動程式。也就是說，必要時通用調節調控器會呼叫它來與硬體通訊，以便更改 CPU 的 P-state（特別是，schedutil 調控器可以直接從排程程式上下文中呼叫它）。
在此模式下，intel_pstate 可以與 sysfs 中 scaling_available_governors 策略屬性列出的所有（通用）調節調控器一起使用（並且不使用上述 P-state 選擇演算法）。然後，它負責配置與 CPU 對應的策略物件，並向 CPUFreq 核心（以及附加到策略物件的調節調控器）提供有關硬體支援的最大和最小操作頻率的準確資訊（包括所謂的“turbo”頻率範圍）。換句話說，在被動模式下，intel_pstate 將所有可用的 P-state 範圍公開給 CPUFreq 核心。但是，在此模式下，驅動程式不向 CPU 排程程式註冊利用率更新回撥，並且 scaling_cur_freq 資訊來自 CPUFreq 核心（並且是當前調節調控器為給定策略選擇的最後一個頻率）。
Turbo P-state 支援¶
在大多數情況下，intel_pstate 可用的整個 P-state 範圍可以分為兩個子範圍，它們對應於不同型別的處理器行為，高於和低於一個邊界，該邊界在下文中將被稱為“turbo 閾值”。
高於 turbo 閾值的 P-state 被稱為“turbo P-state”，它們所屬的整個 P-state 子範圍被稱為“turbo 範圍”。這些名稱與 Turbo Boost 技術相關，該技術允許多核處理器在有足夠的功率且不會導致超過處理器封裝的熱包絡的情況下，機會性地增加一個或多個核心的 P-state。
具體來說，如果軟體將 CPU 核心的 P-state 設定在 turbo 範圍內（即，高於 turbo 閾值），則允許處理器接管該核心的效能調節控制，並使其進入其選擇的 turbo P-state。但是，不同的處理器代系對該許可權的解釋不同。也就是說，Sandy Bridge 代系的處理器永遠不會使用高於軟體為給定核心設定的最後一個 P-state 的任何 P-state，即使它在 turbo 範圍內，而所有後來的處理器代系都將其視為使用 turbo 範圍內任何 P-state 的許可證，甚至高於軟體設定的 P-state。換句話說，在這些處理器上，設定 turbo 範圍內的任何 P-state 都將使處理器能夠將給定核心置於所有 turbo P-state 中，直至幷包括其認為合適的最高支援的 P-state。
turbo P-state 的一個重要特性是它們不可持續。更準確地說，無法保證任何 CPU 能夠無限期地保持在任何這些狀態中，因為處理器封裝內的功率分配可能會隨著時間的推移而變化，或者如果 turbo P-state 使用的時間過長，可能會超過其設計的散熱包絡。
反過來，低於 turbo 閾值的 P-state 通常是可持續的。事實上，如果軟體設定了其中一個 P-state，則預計處理器不會將其更改為較低的 P-state，除非在熱應力或違反功率限制的情況下（例如，如果同時為同一封裝中的另一個 CPU 設定了更高的 P-state，則仍然可以使用更高的 P-state）。
某些處理器允許多個核心同時處於 turbo P-state 中，但可以為其設定的最大 P-state 通常取決於同時執行的核心數。可以同時為 3 個核心設定的最大 turbo P-state 通常低於 2 個核心的類似最大 P-state，而後者又通常低於可以為 1 個核心設定的最大 turbo P-state。因此，單核最大 turbo P-state 是總體支援的最大 P-state。
支援的最大 turbo P-state、turbo 閾值（支援的最大非 turbo P-state）和支援的最小 P-state 特定於處理器型號，可以透過讀取處理器的特定於型號的暫存器 (MSR) 來確定。此外，某些處理器支援可配置 TDP（熱設計功率）功能，並且在啟用該功能時，turbo 閾值實際上變為可配置的值，可以由平臺韌體設定。
與 ACPI 表中的 _PSS 物件不同，intel_pstate 始終將整個可用 P-state 範圍（包括整個 turbo 範圍）公開給 CPUFreq 核心（以及被動模式下的通用調節調控器）。相對於基於 ACPI 的 CPU 效能調節，這通常會導致在使用 intel_pstate 時更頻繁地設定 turbo P-state（有關更多資訊，請參見下面的 acpi-cpufreq）。
此外，由於 intel_pstate 始終知道真正的 turbo 閾值是什麼（即使在處理器中啟用了可配置 TDP 功能），因此其 sysfs 中的 no_turbo 屬性（如下面的 no-turbo 屬性中所述）應在所有情況下都按預期工作（也就是說，如果設定為停用 turbo P-state，則應始終阻止 intel_pstate 使用它們）。
處理器支援¶
為了處理給定的處理器，intel_pstate 需要知道許多不同的資訊，包括
支援的最小 P-state。
支援的最大 非 turbo P-state。
是否完全支援 turbo P-state。
支援的最大 單核 turbo P-state（如果支援 turbo P-state）。
用於將驅動程式的 P-state 內部表示形式轉換為頻率以及反之的調節公式。
通常，獲取該資訊的方法特定於處理器型號或系列。儘管通常可以從處理器本身獲取所有資訊（使用特定於型號的暫存器），但在某些情況下，還需要查閱硬體手冊才能獲取該資訊。
因此，intel_pstate 中有一個受支援的處理器列表，如果檢測到的處理器不在該列表中，除非它支援 HWP 功能，否則驅動程式初始化將失敗。[對於支援 HWP 功能的所有處理器，獲取上述所有資訊的介面都是相同的，這就是為什麼 intel_pstate 可以與所有處理器一起工作。]
對混合處理器的支援¶
intel_pstate 支援的某些處理器包含兩種或多種型別的 CPU 核心，這些核心的最大 turbo P-state、效能與功耗特性、快取大小以及其他屬性各不相同。它們通常被稱為混合處理器。為了支援它們，intel_pstate 需要啟用 HWP，並且它假定 HWP 效能單元對於系統中的所有 CPU 都是相同的，因此給定的 HWP 效能級別始終代表大致相同的物理效能，而不管核心 (CPU) 型別如何。
具有 SMT 的混合處理器¶
在至少一個核心上啟用 SMT（同步多執行緒處理），在 Intel 處理器的上下文中也稱為超執行緒 (HT) 的系統上，intel_pstate 會向 CPU 分配基於效能的優先順序。也就是說，給定 CPU 的優先順序反映了其最高的 HWP 效能級別，這會導致 CPU 排程程式通常更喜歡效能更高的 CPU，因此當其他 CPU 完全載入時，會使用效能較低的 CPU。但是，SMT 對等項（即，共享一個物理核心的邏輯 CPU）以特殊方式處理，以便如果其中一個正在使用中，則其他對等項的有效優先順序將降低到其他物理核心中的 CPU 的優先順序之下。
這種方法在大多數情況下最大限度地提高了效能，但不幸的是，它也導致在一些重要場景中過度使用能量，例如影片播放，這通常是不希望的。雖然在啟用 SMT 的情況下沒有其他可行的選擇，因為 SMT 對等項的有效容量和利用率很難確定，但可以在更節能的方式下處理沒有 SMT 的混合處理器。
容量感知排程支援¶
預設情況下，CPU 排程程式中的容量感知排程 (CAS) 支援由沒有 SMT 的混合處理器上的 intel_pstate 啟用。CAS 通常會導致排程程式將任務放在 CPU 上，只要其上有足夠的備用容量，並且如果給定任務的利用率太高，則該任務將需要轉移到其他位置。
由於 CAS 會考慮 CPU 容量，因此它不需要 CPU 優先順序劃分，並且它允許在效能更高和效能更低的 CPU 之間更對稱地分配任務。一旦放置在具有足夠容量容納它的 CPU 上，任務就可以繼續在那裡執行，而不管其他 CPU 是否完全載入，因此平均而言，CAS 會降低效能更高的 CPU 的利用率，這會導致能量使用更加平衡，因為效能更高的 CPU 通常比效能更低的 CPU 的能源效率更低。
為了使用 CAS，排程程式需要知道系統中每個 CPU 的容量，並且需要能夠計算 CPU 的縮放不變利用率，因此 intel_pstate 向其提供所需的資訊。
首先，每個 CPU 的容量由其最高的 HWP 效能級別（乘以 1024）與系統中效能最高的 CPU 的最高 HWP 效能級別的比率表示，這樣做是因為 HWP 效能單元對於所有 CPU 都是相同的。其次，由排程程式執行的頻率不變性計算（始終以相同的單位表示 CPU 利用率，而不管其當前執行的頻率如何）進行了調整，以考慮 CPU 容量。當 intel_pstate 已向 CPUFreq 核心註冊自身並且它已經確定它正在沒有 SMT 的混合處理器上執行時，所有這些都會發生。
能量感知排程支援¶
如果在核心配置期間已設定 CONFIG_ENERGY_MODEL，並且 intel_pstate 在沒有 SMT 的混合處理器上執行，則除了啟用 CAS 之外，它還會為處理器註冊能量模型。如果使用 schedutil 作為 CPUFreq 調控器，這允許在 CPU 排程程式中啟用能量感知排程 (EAS) 支援，這需要 intel_pstate 在被動模式下執行。
intel_pstate 註冊的能量模型是人工的（也就是說，它基於抽象成本值，並且不包括任何實際功率數），並且它相對簡單，可以避免排程程式中不必要的計算。在其中，對於系統中的每個 CPU 都有一個性能域，並且這些效能域的成本值的選擇方式是，在效能較低（小型）CPU 上執行任務似乎總是比在效能更高（大型）CPU 上執行任務更便宜。但是，對於同一型別的兩個 CPU，成本差異取決於其當前利用率，並且當前利用率較高的 CPU 通常似乎是給定任務的更昂貴的目標。這有助於平衡同一型別 CPU 之間的負載。
由於 EAS 在 CAS 之上工作，因此高利用率任務總是遷移到具有足夠容量容納它們的 CPU，但由於 EAS，低利用率任務傾向於放置在排程程式認為成本較低的 CPU 上。實際上，這會導致效能較低和負載較低的 CPU 成為首選，只要它們有足夠的備用容量來執行給定的任務，這通常會導致降低能量使用。
可以透過檢視 debugfs 中的 energy_model 目錄來檢查 intel_pstate 建立的能量模型（typlically 安裝在 /sys/kernel/debug/ 上）。
sysfs 中的使用者空間介面¶
全域性屬性¶
intel_pstate 在 sysfs 中公開了幾個全域性屬性（檔案），以在系統級別控制其功能。它們位於 /sys/devices/system/cpu/intel_pstate/ 目錄中，並影響所有 CPU。
如果將 intel_pstate=per_cpu_perf_limits 引數傳遞給核心，則其中一些屬性不存在。
max_perf_pct驅動程式允許設定的最大 P-state，以最大支援的效能級別（支援的最高 turbo P-state）的百分比表示。
如果核心命令列中存在
intel_pstate=per_cpu_perf_limits引數，則不會公開此屬性。min_perf_pct驅動程式允許設定的最小 P-state，以最大支援的效能級別（支援的最高 turbo P-state）的百分比表示。
如果核心命令列中存在
intel_pstate=per_cpu_perf_limits引數，則不會公開此屬性。num_pstates處理器支援的 P 狀態數量（包括 0 到 255，包含 0 和 255），包括 Turbo 和非 Turbo P 狀態（參見 Turbo P 狀態支援）。
只有當該屬性的值對於系統中所有 CPU 都相同時，才會顯示此屬性。
此屬性的值不受
no_turbo設定的影響，如下文 所述。此屬性為只讀。
turbo_pctTurbo 範圍大小與支援的 P 狀態整個範圍大小的比率，以百分比表示。
只有當該屬性的值對於系統中所有 CPU 都相同時，才會顯示此屬性。
此屬性為只讀。
no_turbo如果設定（等於 1），則驅動程式不允許設定任何 Turbo P 狀態（參見 Turbo P 狀態支援）。 如果未設定（等於 0，這是預設值），則驅動程式可以設定 Turbo P 狀態。[請注意，
intel_pstate不支援通用的boost屬性（某些其他調頻驅動程式支援），此屬性已由該屬性替換。]此屬性不會影響提供給
CPUFreq核心並透過策略介面公開的最大支援頻率值，但它會影響每個策略 P 狀態限制的最大可能值（有關詳細資訊，請參見下文 策略屬性的解釋）。hwp_dynamic_boost僅當
intel_pstate在處理器中以 啟用 HWP 功能的活動模式執行時，才會顯示此屬性。 如果設定（等於 1），則每當先前等待 I/O 的任務被選擇在給定的邏輯 CPU 上執行時，都會導致最小 P 狀態限制在短時間內動態增加（此機制的目的是提高效能）。此設定對最小 P 狀態限制直接設定為最高非 Turbo P 狀態或高於該狀態的邏輯 CPU 沒有影響。
status驅動程式的操作模式：“active”、“passive”或“off”。
- “active”（活動）
驅動程式功能正常，並且處於 活動模式。
- “passive”（被動）
驅動程式功能正常，並且處於 被動模式。
- “off”（關閉）
驅動程式功能不正常（它未註冊為
CPUFreq核心的調頻驅動程式）。
可以寫入此屬性以更改驅動程式的操作模式或取消註冊。寫入它的字串必須是它的可能值之一，如果成功，寫入將導致驅動程式切換到該字串表示的操作模式，或者在“off”情況下取消註冊。[實際上，從活動模式切換到被動模式或反之會導致驅動程式被取消註冊並再次註冊，並使用一組不同的回撥，因此它的所有設定（全域性設定以及每個策略的設定）都將重置為預設值，可能取決於目標操作模式。]
energy_efficiency（能效）僅在具有與 Kaby Lake 或 Coffee Lake 桌面 CPU 型號匹配的 CPU 的平臺上才會顯示此屬性。 預設情況下，如果啟用了 HWP，則在這些 CPU 型號上會停用能效最佳化。啟用能效最佳化可能會限制啟用或不啟用 HWP 功能時的最大工作頻率。如果啟用了 HWP，則僅在 Turbo 頻率範圍內進行最佳化。如果未啟用，則在整個可用頻率範圍內進行最佳化。將此屬性設定為“1”會啟用能效最佳化，設定為“0”會停用最佳化。
策略屬性的解釋¶
如果 intel_pstate 是當前的調頻驅動程式，則在 CPU 效能調頻中描述的某些 CPUFreq 策略屬性的解釋是特殊的，並且通常取決於驅動程式的操作模式。
首先，cpuinfo_max_freq、cpuinfo_min_freq 和 scaling_cur_freq 屬性的值是透過將特定於處理器的乘數應用於 intel_pstate 使用的內部 P 狀態表示來生成的。此外，scaling_max_freq 和 scaling_min_freq 屬性的值受驅動程式允許設定的最大 P 狀態對應頻率的限制。
如果設定了 no_turbo 全域性屬性，則驅動程式不允許使用 Turbo P 狀態，因此 scaling_max_freq 和 scaling_min_freq 的最大值限制為最大非 Turbo P 狀態頻率。因此，設定 no_turbo 會導致 scaling_max_freq 和 scaling_min_freq 降低到該值（如果之前高於該值）。但是，取消設定 no_turbo 後，將恢復 scaling_max_freq 和 scaling_min_freq 的舊值，除非在設定 no_turbo 後寫入了這些屬性。
如果未設定 no_turbo，則 scaling_max_freq 和 scaling_min_freq 的最大可能值對應於最大支援的 Turbo P 狀態，這也是任何情況下 cpuinfo_max_freq 的值。
接下來，如果 intel_pstate 在 活動模式下工作，則以下策略屬性具有特殊含義
scaling_available_governors由
intel_pstate提供的 P 狀態選擇演算法列表。scaling_governor當前與給定策略一起使用的
intel_pstate提供的 P 狀態選擇演算法。scaling_cur_freq對於給定策略表示的 CPU，在 CPU 排程程式為該 CPU 上次兩次呼叫驅動程式的利用率更新回撥之間的時間間隔內，CPU 的平均 P 狀態的頻率。
如果在處理器中啟用了 HWP 功能，則會顯示另一個策略屬性
base_frequency顯示 CPU 的基本頻率。高於此頻率的任何頻率都將在 Turbo 頻率範圍內。
這些屬性在被動模式下的含義與其他調頻驅動程式相同。
此外，intel_pstate 的 scaling_driver 屬性的值取決於驅動程式的操作模式。即，它要麼是“intel_pstate”（在 活動模式下），要麼是“intel_cpufreq”（在 被動模式下）。
P 狀態限制的協調¶
intel_pstate 允許透過兩種方式設定 P 狀態限制：藉助 max_perf_pct 和 min_perf_pct 全域性屬性或透過 scaling_max_freq 和 scaling_min_freq CPUFreq 策略屬性。這些限制之間的協調基於以下規則，無論驅動程式的當前操作模式如何
所有 CPU 都受全侷限制的影響（即，不能要求它們比全域性最大值執行更快，也不能要求它們比全域性最小值執行更慢）。
每個單獨的 CPU 都受其自己的每個策略限制的影響（即，不能要求它比其自己的每個策略的最大值執行更快，也不能要求它比其自己的每個策略的最小值執行更慢）。有效效能取決於平臺是否支援每個核心 P 狀態，是否啟用了超執行緒以及當前來自其他 CPU 的效能請求。當平臺不支援每個核心 P 狀態時，如果其他 CPU 當前請求更高的效能，則有效效能可能高於在 CPU 上設定的策略限制。即使支援每個核心 P 狀態，當啟用了超執行緒時，如果同級 CPU 請求更高的效能，則其他同級 CPU 將獲得高於其策略限制的效能。
全侷限制和每個策略的限制可以獨立設定。
在 啟用 HWP 功能的活動模式下，只要限制發生變化，結果有效值就會寫入硬體暫存器，以便請求其內部 P 狀態選擇邏輯始終在這些限制內設定 P 狀態。否則，縮放調控器（在 被動模式下）和驅動程式每次在為 CPU 設定新的 P 狀態之前都會考慮這些限制。
此外，如果將 intel_pstate=per_cpu_perf_limits 命令列引數傳遞給核心，則根本不公開 max_perf_pct 和 min_perf_pct，並且設定限制的唯一方法是使用策略屬性。
能耗與效能提示¶
如果在處理器中啟用了硬體管理的 P 狀態 (HWP)，則在 sysfs 中的每個 CPUFreq 策略目錄中都會顯示其他屬性，這些屬性旨在允許使用者空間幫助 intel_pstate 透過將其專注於效能或能效，或者介於兩者之間的某個位置來調整處理器的內部 P 狀態選擇邏輯。
energy_performance_preference（能耗效能偏好）給定策略（或由其表示的 CPU）的能耗與效能提示的當前值。
可以透過寫入此屬性來更改提示。
energy_performance_available_preferences（能耗效能可用偏好）可以寫入
energy_performance_preference屬性的字串列表。它們表示不同的能耗與效能提示，並且應該是自我解釋的，除了
default表示平臺韌體設定的任何提示值。
寫入 energy_performance_preference 屬性的字串在內部轉換為寫入處理器能耗效能偏好 (EPP) 旋鈕（如果支援）或其能耗效能偏差 (EPB) 旋鈕的整數值。如果存在 EPP 功能，也可以寫入 0 到 255 之間的正整數值。如果不存在 EPP 功能，則不支援將整數值寫入此屬性。在這種情況下，使用者可以使用“/sys/devices/system/cpu/cpu*/power/energy_perf_bias”介面。
[請注意，任務可能會被排程程式的負載平衡演算法從一個 CPU 遷移到另一個 CPU，並且如果為這些 CPU 設定了不同的能耗與效能提示，則可能會導致不良結果。為避免此類問題，最好為所有 CPU 設定相同的能耗與效能提示，或者將每個可能對它們敏感的任務固定到特定的 CPU。]
intel_pstate 與 acpi-cpufreq¶
在 intel_pstate 支援的大多數系統上，平臺韌體提供的 ACPI 表包含 _PSS 物件，這些物件返回可用於 CPU 效能調頻的資訊（有關 _PSS 物件及其返回的資訊格式的詳細資訊，請參閱 ACPI 規範 [3]）。
ACPI _PSS 物件返回的資訊由 acpi-cpufreq 調頻驅動程式使用。在 intel_pstate 支援的系統上，acpi-cpufreq 驅動程式使用相同的硬體 CPU 效能調頻介面，但它可以使用的 P 狀態集受 _PSS 輸出的限制。
在這些系統上，每個 _PSS 物件都返回一個由相應 CPU 支援的 P 狀態列表，該列表基本上是可以由 intel_pstate 在同一系統上使用的 P 狀態範圍的子集，但有一個例外：整個 Turbo 範圍由其中的一項（最上面的一項）表示。按照慣例，_PSS 為該項返回的頻率比它列出的最高非 Turbo P 狀態的頻率高 1 MHz，但為此返回的相應 P 狀態表示（遵循硬體規範）與支援的最大 Turbo P 狀態匹配（或者是特殊值 255，實質上意味著“儘可能高”）。
_PSS 返回的 P 狀態列表反映在 acpi-cpufreq 提供給 CPUFreq 核心和調頻調控器的可用頻率表中，並且它報告的最小和最大支援頻率也來自該列表。特別是，考慮到上面描述的 Turbo 範圍的特殊表示，這意味著 acpi-cpufreq 報告的最大支援頻率比 _PSS 列出的最高支援非 Turbo P 狀態的頻率高 1 MHz，這當然會影響調頻調控器做出的決定，除了 powersave 和 performance。
例如，如果給定的調控器嘗試選擇與估計的 CPU 負載成比例的頻率，並將 100% 的負載對映到最大支援頻率（可能乘以一個常數），那麼如果 acpi-cpufreq 用作調頻驅動程式，則它將傾向於選擇低於 Turbo 閾值的 P 狀態，因為在這種情況下，Turbo 範圍對應於它可以使用的頻段的一小部分（1 MHz 與 1 GHz 或更高）。因此，它只會為最高負載進入 Turbo 範圍，而其他可能受益於以 Turbo 頻率執行的 50% 以上的負載將被賦予非 Turbo P 狀態。
另一個與此相關的問題可能會出現在支援 可配置 TDP 功能的系統上，該功能允許平臺韌體設定 Turbo 閾值。也就是說，如果這沒有與 _PSS 返回的 P 狀態列表正確協調，則這些列表中可能存在多個與 Turbo P 狀態對應的項，並且可能會出現避免 Turbo 範圍的問題（如果需要或必要）。通常，為了避免總體使用 Turbo P 狀態，acpi-cpufreq 只是避免使用 _PSS 列出的最上面的狀態，但這在它返回的列表中有其他 Turbo P 狀態時是不夠的。
除了上述情況外，acpi-cpufreq 的工作方式類似於 被動模式下的 intel_pstate，只是它可以設定的 P 狀態數量僅限於 ACPI _PSS 物件列出的 P 狀態。
intel_pstate 的核心命令列選項¶
可以使用多個核心命令列選項將早期配置時引數傳遞給 intel_pstate，以便強制執行其特定行為。所有這些選項都必須以 intel_pstate= 字首開頭。
disable（停用）即使處理器支援
intel_pstate，也不將其註冊為調頻驅動程式。active（活動）在 活動模式下注冊
intel_pstate以開始。passive（被動）在 被動模式下注冊
intel_pstate以開始。force（強制）即使在給定系統上首選
acpi-cpufreq，也將intel_pstate註冊為調頻驅動程式，而不是acpi-cpufreq。這可能會阻止某些依賴於 ACPI P 狀態資訊可用的平臺功能（例如散熱控制和功耗限制）按預期執行，因此應謹慎使用。
此選項不適用於
intel_pstate不支援的處理器以及使用pcc-cpufreq調頻驅動程式而不是acpi-cpufreq的平臺上。no_hwp即使處理器支援硬體管理的 P 狀態 (HWP) 功能，也不啟用該功能。
hwp_only僅當處理器支援硬體管理的 P 狀態 (HWP) 功能時，才將
intel_pstate註冊為調頻驅動程式。support_acpi_ppc考慮 ACPI
_PPC效能限制。如果 FADT（固定 ACPI 描述表）中的首選電源管理配置檔案設定為“企業伺服器”或“效能伺服器”，則預設情況下會考慮 ACPI
_PPC限制，並且此選項不起作用。per_cpu_perf_limits使用每個邏輯 CPU 的 P 狀態限制（有關詳細資訊，請參閱 P 狀態限制的協調）。
no_cas不要啟用 容量感知排程，預設情況下在沒有 SMT 的混合系統上啟用該排程。
診斷和調整¶
跟蹤事件¶
有兩個靜態跟蹤事件可用於 intel_pstate 診斷。其中一個是通常由 CPUFreq 使用的 cpu_frequency 跟蹤事件，另一個是特定於 intel_pstate 的 pstate_sample 跟蹤事件。只有當 intel_pstate 在 活動模式下工作時，才會由 intel_pstate 觸發這兩個事件。
以下 shell 命令序列可用於啟用它們並檢視它們的輸出（如果核心通常配置為支援事件跟蹤）
# cd /sys/kernel/tracing/
# echo 1 > events/power/pstate_sample/enable
# echo 1 > events/power/cpu_frequency/enable
# cat trace
gnome-terminal--4510 [001] ..s. 1177.680733: pstate_sample: core_busy=107 scaled=94 from=26 to=26 mperf=1143818 aperf=1230607 tsc=29838618 freq=2474476
cat-5235 [002] ..s. 1177.681723: cpu_frequency: state=2900000 cpu_id=2
如果 intel_pstate 在 被動模式下工作，則 cpu_frequency 跟蹤事件將由 schedutil 調頻調控器（對於它附加的策略）或由 CPUFreq 核心（對於具有其他調頻調控器的策略）觸發。
ftrace¶
ftrace 介面可用於 intel_pstate 的底層診斷。例如，要檢查呼叫設定 P 狀態的函式的頻率，可以將 ftrace 過濾器設定為 intel_pstate_set_pstate()
# cd /sys/kernel/tracing/
# cat available_filter_functions | grep -i pstate
intel_pstate_set_pstate
intel_pstate_cpu_init
...
# echo intel_pstate_set_pstate > set_ftrace_filter
# echo function > current_tracer
# cat trace | head -15
# tracer: function
#
# entries-in-buffer/entries-written: 80/80 #P:4
#
# _-----=> irqs-off
# / _----=> need-resched
# | / _---=> hardirq/softirq
# || / _--=> preempt-depth
# ||| / delay
# TASK-PID CPU# |||| TIMESTAMP FUNCTION
# | | | |||| | |
Xorg-3129 [000] ..s. 2537.644844: intel_pstate_set_pstate <-intel_pstate_timer_func
gnome-terminal--4510 [002] ..s. 2537.649844: intel_pstate_set_pstate <-intel_pstate_timer_func
gnome-shell-3409 [001] ..s. 2537.650850: intel_pstate_set_pstate <-intel_pstate_timer_func
<idle>-0 [000] ..s. 2537.654843: intel_pstate_set_pstate <-intel_pstate_timer_func