CPU 效能調整¶

版權:: © 2017 Intel Corporation
作者:: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

CPU 效能調整的概念¶

大多數現代處理器都能夠在多種不同的時鐘頻率和電壓配置下執行，通常稱為工作效能點或 P 狀態（在 ACPI 術語中）。一般來說，時鐘頻率越高，電壓越高，CPU 在單位時間內可以完成的指令就越多，但同時，時鐘頻率越高，電壓越高，CPU 在給定 P 狀態下單位時間內消耗的能量（或汲取的功率）就越多。因此，CPU 容量（單位時間內可以執行的指令數量）與 CPU 汲取的功率之間存在著一種自然的權衡。

在某些情況下，需要甚至必須儘可能快地執行程式，因此沒有理由使用任何不同於最高 P 狀態的 P 狀態（即，可用的最高效能頻率/電壓配置）。然而，在某些其他情況下，可能沒有必要如此快速地執行指令，並且在相對較長的時間內保持最高的可用 CPU 容量而不完全利用它可能被認為是浪費。由於散熱或電源容量原因或類似原因，也可能無法在太長時間內保持最大 CPU 容量。為了涵蓋這些情況，存在一些硬體介面，允許 CPU 在不同的頻率/電壓配置之間切換，或者（在 ACPI 術語中）進入不同的 P 狀態。

通常，它們與演算法一起用於估計所需的 CPU 容量，以便決定將 CPU 置於哪個 P 狀態。當然，由於系統的利用率通常會隨時間變化，因此必須定期重複此操作。發生這種情況的活動稱為 CPU 效能調整或 CPU 頻率調整（因為它涉及調整 CPU 時鐘頻率）。

Linux 中的 CPU 效能調整¶

Linux 核心透過 CPUFreq（CPU 頻率調整）子系統支援 CPU 效能調整，該子系統由三個程式碼層組成：核心層、調整調控器和調整驅動程式。

CPUFreq 核心層為所有支援 CPU 效能調整的平臺提供通用的程式碼基礎設施和使用者空間介面。它定義了其他元件執行的基本框架。

調整調控器實現了用於估計所需 CPU 容量的演算法。一般來說，每個調控器都實現一個可能引數化的調整演算法。

調整驅動程式與硬體通訊。它們向調整調控器提供有關可用 P 狀態（或在某些情況下為 P 狀態範圍）的資訊，並訪問特定於平臺的硬體介面以根據調整調控器的請求更改 CPU P 狀態。

原則上，所有可用的調整調控器都可以與每個調整驅動程式一起使用。這種設計基於這樣的觀察：效能調整演算法用於 P 狀態選擇的資訊在大多數情況下可以用平臺無關的形式表示，因此應該可以使用以完全相同的方式實現的相同效能調整演算法，而不管使用哪個調整驅動程式。因此，同一組調整調控器應該適用於每個受支援的平臺。

然而，對於基於硬體本身提供的資訊的效能調整演算法，例如透過反饋暫存器，該觀察結果可能不成立，因為該資訊通常特定於其來源的硬體介面，並且可能不容易以抽象的、平臺無關的方式表示。因此，CPUFreq 允許調整驅動程式繞過調控器層並實現其自己的效能調整演算法。這是由 intel_pstate 調整驅動程式完成的。

`CPUFreq` 策略物件¶

在某些情況下，P 狀態控制的硬體介面由多個 CPU 共享。例如，同一個暫存器（或一組暫存器）用於同時控制多個 CPU 的 P 狀態，並且寫入該暫存器會同時影響所有這些 CPU。

共享硬體 P 狀態控制介面的 CPU 集由 CPUFreq 表示為 struct cpufreq_policy 物件。為了保持一致性，當給定集合中只有一個 CPU 時，也使用 struct cpufreq_policy。

CPUFreq 核心層為系統中的每個 CPU 維護一個指向 struct cpufreq_policy 物件的指標，包括當前離線的 CPU。如果多個 CPU 共享同一個硬體 P 狀態控制介面，則與它們對應的所有指標都指向同一個 struct cpufreq_policy 物件。

CPUFreq 使用 struct cpufreq_policy 作為其基本資料型別，並且其使用者空間介面的設計基於策略概念。

CPU 初始化¶

首先，必須註冊調整驅動程式才能使 CPUFreq 工作。一次只能註冊一個調整驅動程式，因此調整驅動程式應該能夠處理系統中的所有 CPU。

可以在 CPU 註冊之前或之後註冊調整驅動程式。如果 CPU 較早註冊，則驅動程式核心層會呼叫 CPUFreq 核心層以記錄在調整驅動程式註冊期間所有已註冊的 CPU。反過來，如果在調整驅動程式註冊後註冊了任何 CPU，則將呼叫 CPUFreq 核心層以在它們的註冊時記錄它們。

無論如何，只要 CPUFreq 核心層準備好處理該 CPU，它就會被呼叫以記錄到目前為止它尚未看到的任何邏輯 CPU。[請注意，邏輯 CPU 可能是物理單核處理器，或者多核處理器中的單個核心，或者是物理處理器或處理器核心中的硬體執行緒。在下文中，“CPU”始終表示“邏輯 CPU”，除非另有明確說明，並且“處理器”一詞用於指可能包括多個邏輯 CPU 的物理部分。]

一旦被呼叫，CPUFreq 核心層會檢查是否已為給定的 CPU 設定了策略指標，如果是，則跳過策略物件的建立。否則，將建立一個新的策略物件並對其進行初始化，這涉及在 sysfs 中建立一個新的策略目錄，並且與給定 CPU 對應的策略指標設定為記憶體中新策略物件的地址。

接下來，將呼叫調整驅動程式的 ->init() 回撥，並將新 CPU 的策略指標作為引數傳遞給它。該回調應該初始化給定 CPU 的效能調整硬體介面（或者更準確地說，對於共享其所屬硬體介面的 CPU 集合，由其策略物件表示），並且，如果已為其呼叫策略物件是新的，則設定策略的引數，例如硬體支援的最小和最大頻率、可用頻率表（如果支援的 P 狀態集不是連續範圍）以及屬於同一策略的 CPU 掩碼（包括線上和離線 CPU）。然後核心層使用該掩碼來填充其中所有 CPU 的策略指標。

新策略物件的下一個主要初始化步驟是將調整調控器附加到它（首先，這是由核心命令列或配置確定的預設調整調控器，但稍後可以透過 sysfs 更改）。首先，將指向新策略物件的指標傳遞給調控器的 ->init() 回撥，該回調應該初始化處理給定策略所需的所有資料結構，並可能向其新增調控器 sysfs 介面。接下來，透過呼叫其 ->start() 回撥來啟動調控器。

該回調應該向 CPU 排程程式註冊給定策略的所有線上 CPU 的每個 CPU 利用率更新回撥。CPU 排程程式將在重要事件（例如任務入隊和出隊）時，在排程程式節拍的每次迭代中或通常在 CPU 利用率可能發生變化時（從排程程式的角度來看）呼叫利用率更新回撥。它們應該執行計算以確定要用於給定策略的 P 狀態，並呼叫調整驅動程式以根據 P 狀態選擇對硬體進行更改。根據調整驅動程式和調控器的配置和功能，可以直接從排程程式上下文中或非同步地透過核心執行緒或工作佇列呼叫調整驅動程式。

對於不是新的但先前“不活動”的策略物件（這意味著屬於它們的所有 CPU 都已離線），將採取類似的步驟。在這種情況下，唯一的實際區別是 CPUFreq 核心層將嘗試使用先前與變為“不活動”（並且現在重新初始化）的策略一起使用的調整調控器，而不是預設調控器。

反過來，如果先前離線的 CPU 正在恢復聯機，但與它共享策略物件的其他一些 CPU 已經聯機，則根本不需要重新初始化策略物件。在這種情況下，只需要重新啟動調整調控器，以便它可以將新的線上 CPU 考慮在內。這是透過按此順序為整個策略呼叫調控器的 ->stop 和 ->start() 回撥來實現的。

如前所述，intel_pstate 調整驅動程式繞過了 CPUFreq 的調整調控器層，並提供了它自己的 P 狀態選擇演算法。因此，如果使用 intel_pstate，則調整調控器不會附加到新的策略物件。相反，將呼叫驅動程式的 ->setpolicy() 回撥以註冊每個策略的每個 CPU 利用率更新回撥。這些回撥由 CPU 排程程式以與調整調控器相同的方式呼叫，但在 intel_pstate 情況下，它們既確定要使用的 P 狀態，又一次性地從排程程式上下文中相應地更改硬體配置。

在 CPU 初始化期間建立的策略物件和與其關聯的其他資料結構在調整驅動程式登出時（例如，當包含它的核心模組被解除安裝時）或當給定策略中的最後一個 CPU 登出時被拆除。

`sysfs` 中的策略介面¶

在核心初始化期間，CPUFreq 核心層會在 /sys/devices/system/cpu/ 下建立一個名為 cpufreq 的 sysfs 目錄（kobject）。

該目錄包含一個 policyX 子目錄（其中 X 表示整數），用於 CPUFreq 核心層維護的每個策略物件。每個 policyX 目錄都由 /sys/devices/system/cpu/cpuY/ 下的 cpufreq 符號連結指向（其中 Y 表示整數，該整數可能與 X 表示的整數不同），用於與給定策略關聯（或屬於該策略）的所有 CPU。/sys/devices/system/cpu/cpufreq 中的 policyX 目錄各自包含特定於策略的屬性（檔案），用於控制相應策略物件（即，與它們關聯的所有 CPU）的 CPUFreq 行為。

其中一些屬性是通用的。它們由 CPUFreq 核心層建立，並且它們的行為通常不取決於正在使用哪個調整驅動程式以及哪個調整調控器附加到給定策略。一些調整驅動程式還在 sysfs 中的策略目錄中添加了特定於驅動程式的屬性，以控制驅動程式行為的特定於策略的方面。

/sys/devices/system/cpu/cpufreq/policyX/ 下的通用屬性如下

affected_cpus

屬於此策略的線上 CPU 列表（即，共享 policyX 策略物件表示的硬體效能調整介面）。

bios_limit

如果平臺韌體 (BIOS) 指示作業系統對 CPU 頻率應用上限，則將透過此屬性（如果存在）報告該上限。

限制的存在可能是某些（通常是無意的）BIOS 設定、來自服務處理器的限制或其他基於 BIOS/HW 的機制的結果。

這不包括可以透過通用散熱驅動程式發現的 ACPI 散熱限制。

如果正在使用的調整驅動程式不支援此屬性，則此屬性不存在。

cpuinfo_cur_freq

從此策略所屬的 CPU 的硬體獲得的當前頻率（以 KHz 為單位）。

預計這是硬體實際執行的頻率。如果無法確定該頻率，則不應存在此屬性。

cpuinfo_avg_freq

從硬體提供的反饋中匯出的屬於給定策略的所有 CPU 的平均頻率（以 KHz 為單位），並在跨越最多幾毫秒的時間範圍內報告。

預計這基於硬體實際執行的頻率，因此可能需要專門的硬體支援（例如 ARM 上的 AMU 擴充套件）。如果無法確定，則不應存在此屬性。

請注意，嘗試檢索給定 CPU 的當前頻率失敗將導致相應的錯誤，即：EAGAIN 對於保持空閒的 CPU（在 ARM 上引發）。

cpuinfo_max_freq

屬於此策略的 CPU 可以執行的最大可能工作頻率（以 kHz 為單位）。

cpuinfo_min_freq

屬於此策略的 CPU 可以執行的最小可能工作頻率（以 kHz 為單位）。

cpuinfo_transition_latency

將屬於此策略的 CPU 從一個 P 狀態切換到另一個 P 狀態所花費的時間，以納秒為單位。

如果未知，或者如果已知如此之高以至於調整驅動程式無法與 ondemand 調控器一起使用，則從該屬性的讀取將返回 -1 (CPUFREQ_ETERNAL)。

related_cpus

屬於此策略的所有（線上和離線）CPU 的列表。

scaling_available_frequencies

屬於此策略的 CPU 的可用頻率列表（以 kHz 為單位）。

scaling_available_governors

核心中存在的 CPUFreq 調整調控器的列表，可以附加到此策略，或者（如果正在使用 intel_pstate 調整驅動程式）驅動程式提供的可以應用於此策略的調整演算法的列表。

[請注意，某些調控器是模組化的，可能需要載入核心模組才能使其調控器可用並由此屬性列出。]

scaling_cur_freq

屬於此策略的所有 CPU 的當前頻率（以 kHz 為單位）。

在大多數情況下，這是調整驅動程式使用它提供的調整介面從硬體請求的最後一個 P 狀態的頻率，由於硬體設計和其他限制，該頻率可能無法反映 CPU 實際執行的頻率。

某些架構（例如 x86）可能會嘗試透過此屬性提供更精確地反映當前 CPU 頻率的資訊，但這仍然可能不是硬體當前看到的精確當前 CPU 頻率。但是，此行為僅透過 c:macro:CPUFREQ_ARCH_CUR_FREQ 選項可用。

scaling_driver

當前正在使用的調整驅動程式。

scaling_governor

當前附加到此策略的調整調控器，或者（如果正在使用 intel_pstate 調整驅動程式）驅動程式提供的當前應用於此策略的調整演算法。

此屬性是可讀寫的，寫入它將導致將新的調整調控器附加到此策略，或者將調整驅動程式提供的新調整演算法應用於它（在 intel_pstate 情況下），如寫入此屬性的字串所指示的（該字串必須是上面描述的 scaling_available_governors 屬性列出的名稱之一）。

scaling_max_freq

允許屬於此策略的 CPU 執行的最大頻率（以 kHz 為單位）。

此屬性是可讀寫的，將表示整數的字串寫入它將導致設定新的限制（它不得低於 scaling_min_freq 屬性的值）。

scaling_min_freq

允許屬於此策略的 CPU 執行的最小頻率（以 kHz 為單位）。

此屬性是可讀寫的，將表示非負整數的字串寫入它將導致設定新的限制（它不得高於 scaling_max_freq 屬性的值）。

scaling_setspeed

僅當 userspace 調整調控器附加到給定策略時，此屬性才起作用。

它返回調控器請求的最後一個頻率（以 kHz 為單位），或者可以寫入以設定策略的新頻率。

通用調整調控器¶

CPUFreq 提供可與所有調整驅動程式一起使用的通用調整調控器。如前所述，它們中的每一個都實現一個可能引數化的效能調整演算法。

調整調控器附加到策略物件，並且不同的策略物件可以由不同的調整調控器同時處理（儘管在某些情況下這可能會導致次優結果）。

可以使用 sysfs 中的 scaling_governor 策略屬性隨時更改給定策略物件的調整調控器。

某些調控器公開 sysfs 屬性，以控制或微調它們實現的調整演算法。這些屬性稱為調控器可調引數，可以是全域性的（系統範圍的）或每個策略的，具體取決於正在使用的調整驅動程式。如果驅動程式要求調控器可調引數為每個策略，則它們位於每個策略目錄的子目錄中。否則，它們位於 /sys/devices/system/cpu/cpufreq/ 下的子目錄中。在任何一種情況下，包含調控器可調引數的子目錄的名稱都是提供它們的調控器的名稱。

`performance`¶

當附加到策略物件時，此調控器會導致為該策略請求最高頻率，該頻率在 scaling_max_freq 策略限制內。

請求在當時一次發出，策略的調控器設定為 performance，並在 scaling_max_freq 或 scaling_min_freq 策略限制在那之後更改時發出。

`powersave`¶

當附加到策略物件時，此調控器會導致為該策略請求最低頻率，該頻率在 scaling_min_freq 策略限制內。

請求在當時一次發出，策略的調控器設定為 powersave，並在 scaling_max_freq 或 scaling_min_freq 策略限制在那之後更改時發出。

`userspace`¶

此調控器本身不執行任何操作。相反，它允許使用者空間透過寫入該策略的 scaling_setspeed 屬性來設定其附加的策略的 CPU 頻率。

`schedutil`¶

此調控器使用從 CPU 排程程式獲得的 CPU 利用率資料。它通常被視為 CPU 排程程式的一部分，因此它可以直接訪問排程程式的內部資料結構。

它完全在排程程式上下文中執行，儘管在某些情況下，當它決定應該為給定策略更改 CPU 頻率時，它可能需要非同步呼叫調整驅動程式（這取決於驅動程式是否能夠在排程程式上下文中更改 CPU 頻率）。

此調控器對特定 CPU 的操作取決於為該 CPU 呼叫其利用率更新回撥的排程類。如果是 RT 或截止時間排程類呼叫它，則調控器會將頻率提高到允許的最大值（即 scaling_max_freq 策略限制）。反過來，如果是 CFS 排程類呼叫它，則調控器將使用給定 CPU 的根控制組的每個實體負載跟蹤 (PELT) 指標作為 CPU 利用率估計（有關 PELT 機制的描述，請參閱 每個實體負載跟蹤 LWN.net 文章 [1]）。然後，根據以下公式計算要應用的新 CPU 頻率

f = 1.25 * f_0 * util / max

其中 util 是 PELT 數，max 是 util 的理論最大值，f_0 是給定策略的最大可能 CPU 頻率（如果 PELT 數與頻率無關），或者當前 CPU 頻率（否則）。

此調控器還採用一種機制，允許它臨時提高最近一直在 I/O 上等待的任務的 CPU 頻率，稱為“I/O 等待提升”。當排程程式將 SCHED_CPUFREQ_IOWAIT 標誌傳遞給調控器回撥時，就會發生這種情況，這會導致頻率立即上升到允許的最大值，然後隨著時間的推移回落到上述公式返回的值。

此調控器僅公開一個可調引數

rate_limit_us

兩個調控器計算的連續執行之間必須經過的最短時間（以微秒為單位）（預設值：調整驅動程式的轉換延遲的 1.5 倍或最大 2 毫秒）。

此可調引數的目的是減少調控器的排程程式上下文開銷，如果沒有它，開銷可能會過大。

此調控器通常被認為是較舊的 ondemand 和 conservative 調控器（如下所述）的替代品，因為它更簡單且與 CPU 排程程式整合得更緊密，它在 CPU 上下文切換等方面的開銷不太顯著，並且它使用排程程式自己的 CPU 利用率指標，因此原則上它的決策不應與排程程式的其他部分做出的決策相矛盾。

`ondemand`¶

此調控器使用 CPU 負載作為 CPU 頻率選擇指標。

為了估計當前 CPU 負載，它會測量其工作例程的連續呼叫之間經過的時間，並計算給定 CPU 未處於空閒狀態的時間段的比例。非空閒（活動）時間與總 CPU 時間的比率被視為負載的估計值。

如果此調控器附加到多個 CPU 共享的策略，則會估計所有 CPU 的負載，並將最大結果作為整個策略的負載估計值。

此調控器的工作例程必須在程序上下文中執行，因此它是非同步呼叫的（透過工作佇列），並且如果需要，CPU P 狀態會從那裡更新。因此，此調控器的排程程式上下文開銷是最小的，但它會導致相對頻繁地發生額外的 CPU 上下文切換，並且由它觸發的 CPU P 狀態更新可能相對不規則。此外，它透過執行減少 CPU 空閒時間的程式碼來影響其自身的 CPU 負載指標（即使 CPU 空閒時間僅略微減少）。

它通常選擇與估計負載成比例的 CPU 頻率，以便 cpuinfo_max_freq 策略屬性的值對應於負載 1（或 100%），並且 cpuinfo_min_freq 策略屬性的值對應於負載 0，除非負載超過（可配置的）加速閾值，在這種情況下，它將直接達到它允許使用的最高頻率（scaling_max_freq 策略限制）。

此調控器公開以下可調引數

sampling_rate

這是調控器的工作例程應該執行的頻率，以微秒為單位。

通常，它設定為 2000（2 毫秒）量級的值。它的預設值是在此調控器附加到的每個策略上將 cpuinfo_transition_latency 增加 50% 的緩衝空間。最小值通常是兩個排程程式節拍的長度。

如果此可調引數是每個策略的，則以下 shell 命令將它表示的時間設定為轉換延遲的 1.5 倍（預設值）

# echo `$(($(cat cpuinfo_transition_latency) * 3 / 2))` > ondemand/sampling_rate

up_threshold

如果估計的 CPU 負載高於此值（以百分比為單位），則調控器會將頻率設定為策略允許的最大值。否則，所選頻率將與估計的 CPU 負載成比例。

ignore_nice_load

如果設定為 1（預設值為 0），則會導致 CPU 負載估計程式碼將花費在執行“nice”級別大於 0 的任務上的 CPU 時間視為 CPU 空閒時間。

如果系統中存在在決定以什麼頻率執行 CPU 時不應考慮的任務，這可能很有用。然後，要實現這一點，只需將這些任務的“nice”級別提高到 0 以上，並將此屬性設定為 1。

sampling_down_factor

臨時乘數，介於 1（預設值）和 100 之間（包括 100），以應用於 sampling_rate 值，如果 CPU 負載高於 up_threshold。

這會導致延遲調控器工作例程的下一次執行（在將頻率設定為允許的最大值之後），因此頻率在最長時間內保持在最大級別。

可以透過以維護最大 CPU 容量的額外能量為代價來避免某些突發性工作負載中的頻率波動。

powersave_bias

應用於調控器的原始頻率目標（包括估計的 CPU 負載超過 up_threshold 值時使用的最大值）的減少因子或 AMD 頻率靈敏度節能偏置驅動程式 (drivers/cpufreq/amd_freq_sensitivity.c) 的靈敏度閾值，介於 0 和 1000 之間（包括 0 和 1000）。

如果未載入 AMD 頻率靈敏度節能偏置驅動程式，則要應用的有效頻率由下式給出

f * (1 - powersave_bias / 1000)

其中 f 是調控器的原始頻率目標。在這種情況下，此屬性的預設值為 0。

如果載入了 AMD 頻率靈敏度節能偏置驅動程式，則此屬性的預設值為 400，並且以不同的方式使用。

在 Family 16h（及更高版本）的 AMD 處理器上，有一種機制可以從硬體獲取工作負載敏感度的測量值，範圍為 0 到 100%（含）。該值可用於估計在 CPU 上執行的工作負載的效能如何響應頻率變化。

敏感度為 0（記憶體密集型或 IO 密集型）的工作負載的效能預計不會因 CPU 頻率的增加而有所提高，而敏感度為 100%（CPU 密集型）的工作負載如果 CPU 頻率增加，預計效能會更好。

如果工作負載敏感度低於 powersave_bias 值所代表的閾值，則敏感度省電偏置驅動程式將導致調速器選擇低於其原始目標的頻率，從而避免過度配置那些無法從以更高 CPU 頻率執行中受益的工作負載。

`conservative`¶

此調控器使用 CPU 負載作為 CPU 頻率選擇指標。

它以與上面描述的 ondemand 調速器相同的方式估計 CPU 負載，但它實現的 CPU 頻率選擇演算法是不同的。

也就是說，它避免在短時間內顯著改變頻率，這可能不適用於電源容量有限的系統（例如，電池供電）。為了實現這一點，它以相對小的步長，一次一步地向上或向下改變頻率 - 這取決於估計的 CPU 負載是否超過了（可配置的）閾值。

此調控器公開以下可調引數

freq_step

頻率步長，以調速器允許設定的最大頻率（scaling_max_freq 策略限制）的百分比表示，範圍在 0 到 100 之間（預設為 5）。

這是允許頻率一次改變多少。將其設定為 0 將導致使用預設頻率步長（5%），將其設定為 100 實際上會導致調速器定期在 scaling_min_freq 和 scaling_max_freq 策略限制之間切換頻率。

down_threshold

閾值（以百分比表示，預設為 20），用於確定頻率變化的direction。

如果估計的 CPU 負載大於此值，頻率將上升（freq_step）。如果負載小於此值（並且 sampling_down_factor 機制未生效），頻率將下降。否則，頻率不會改變。

sampling_down_factor

頻率降低延遲因子，範圍在 1（預設）到 10（含）之間。

它實際上導致頻率下降的速度比上升的速度慢 sampling_down_factor 倍。

頻率加速支援¶

背景¶

某些處理器支援一種機制，可以在某些條件下暫時（並且高於整個封裝的可持續頻率閾值）提高多核封裝中某些核心的工作頻率，例如，如果整個晶片沒有被充分利用並且低於其預期的熱或功率預算。

不同的供應商使用不同的名稱來指代此功能。對於 Intel 處理器，它被稱為“Turbo Boost”，AMD 稱其為“Turbo-Core”或（在技術文件中）“Core Performance Boost”等等。通常，不同的供應商也以不同的方式實現它。為了簡潔起見，此處使用簡單術語“頻率加速”來指代所有這些實現。

頻率加速機制可以是基於硬體的，也可以是基於軟體的。如果它是基於硬體的（例如，在 x86 上），則觸發加速的決定由硬體做出（儘管通常它需要將硬體置於一種特殊狀態，在該狀態下它可以控制 CPU 頻率在一定限制內）。如果它是基於軟體的（例如，在 ARM 上），則縮放驅動程式決定是否觸發加速以及何時觸發。

`sysfs` 中的 `boost` 檔案¶

此檔案位於 /sys/devices/system/cpu/cpufreq/ 下，並控制整個系統的“加速”設定。如果底層縮放驅動程式不支援頻率加速機制（或者支援它，但提供了驅動程式特定的介面來控制它，例如 intel_pstate），則此檔案不存在。

如果此檔案中的值為 1，則頻率加速機制已啟用。這意味著硬體可以置於可以觸發加速的狀態（在基於硬體的情況下），或者允許軟體觸發加速（在基於軟體的情況下）。這並不意味著當前系統中的任何 CPU 都在實際使用加速。它僅表示使用頻率加速機制的許可權（由於其他原因可能永遠不會使用）。

如果此檔案中的值為 0，則頻率加速機制已停用且根本無法使用。

可以寫入此檔案的唯一值是 0 和 1。

加速控制旋鈕的原理¶

頻率加速機制通常旨在幫助在低於軟體解析度的時間尺度（例如，低於排程程式滴答間隔）上實現最佳 CPU 效能，並且對於許多工作負載來說，它顯然是合適的，但在某些情況下可能會導致問題。

因此，許多系統可以在平臺韌體 (BIOS) 設定中停用頻率加速機制，但這需要重新啟動系統才能根據需要調整設定，這至少在某些情況下可能不切實際。例如

加速意味著超頻處理器，儘管在受控條件下。通常，處理器的能耗會隨著頻率和電壓的升高而增加，即使是暫時的。這在切換到容量有限的電源（例如電池）的系統上可能是不希望的，因此在系統執行時停用加速機制的能力可能會有所幫助（但這取決於工作負載）。

在某些情況下，確定性行為比效能或能耗（或兩者）更重要，因此在系統執行時停用加速的能力可能會很有用。

為了檢查頻率加速機制本身的影響，最好能夠在啟用和停用加速的情況下執行測試，最好在此期間不要重新啟動系統。

執行基準測試時，可重複的結果非常重要。由於加速功能取決於整個封裝的負載，因此單執行緒效能可能會因此而變化，這有時會導致無法重現的結果。可以透過在執行對該問題敏感的基準測試之前停用頻率加速機制來避免這種情況。

舊版 AMD `cpb` 旋鈕¶

AMD powernow-k8 縮放驅動程式支援一個非常類似於全域性 boost 的 sysfs 旋鈕。它用於停用/啟用某些 AMD 處理器的“核心效能加速”功能。

如果存在，該旋鈕位於 sysfs 中的每個 CPUFreq 策略目錄中（/sys/devices/system/cpu/cpufreq/policyX/），並稱為 cpb，這表明了一個更精細的控制介面。然而，實際的實現是在系統範圍內進行的，並且為一個策略設定該旋鈕會導致同時為所有其他策略設定相同的值。

該旋鈕仍然在支援其底層硬體功能的 AMD 處理器上受支援，但可以從核心中配置出來（透過 CONFIG_X86_ACPI_CPUFREQ_CPB 配置選項），並且全域性 boost 旋鈕始終存在。因此，始終可以使用 boost 旋鈕代替 cpb 旋鈕，強烈建議這樣做，因為它與其他所有系統的做法更加一致（並且 cpb 旋鈕將來可能不再受支援）。

對於任何沒有底層硬體功能的處理器（例如，所有 Intel 處理器），cpb 旋鈕永遠不會存在，即使設定了 CONFIG_X86_ACPI_CPUFREQ_CPB 配置選項。

Linux 核心

目錄

本頁

CPU 效能調整¶