CPU电源管理/C-States/P-States

一、CPU的功率与功耗

电气工程中教授的第一个主题是功率 = 电流 * 电压 (P = I * V)。 我们可以将功率视为有水流过的管道。 电流实际上是水流的速度，而电压是管道的尺寸。 如果管道很小（电压低），则很难输送大量水（电）。 同样，如果您可以减慢水流的速度，您就可以减少用水量。 CPU 中的电源管理就是有效（动态）控制电流和电压，以最大限度地降低功耗，同时提供最终用户所需的性能。

1、Logic Power

CPU的功率主要可以分为两个部分，一部分是逻辑功率，也就是指令执行的功率，另一部分是IO功率，也就是连接CPU内部和外部的IO部分消耗的功率。逻辑功率又可以分为两部分，动态功率(Active Power)和漏功率(Leakage Power)。动态功率可以理解为晶体管翻转所需要的功率，而漏功率则可以理解为保证晶体管状态的漏功率。动态功率占据CPU功率的主要部分，特别是CPU处于高利用率的情况之下。提高性能的重要手段就是提高CPU主频，然而提高主频需要提高电压。这一点是由于晶体管的特性决定，一般来说电压和频率的关系为”电压是频率的二次方”的关系，也就是频率越高，所需电压越大，而频率较低时，晶体管反转只需要较小的电压。相对于CPU的逻辑功率，CPU功耗也是由两块组成，其中一部分是动态功耗，是CPU运行起来让晶体管打开或者关闭的功耗。另一部分是静态功耗，也叫漏电功耗，是一个保持晶体管稳态的功耗。

当CPU中的逻辑在0和1之间转换时，功耗被消耗。晶体管实际上是每个充电和放电(在这个过程中消耗能量)的小电容。这被称为CPU的有功功率。

有功功率有两个组成部分:

• CPU中运行的时钟消耗的电源;
• 执行计算的实际逻辑消耗的功耗;

在给定周期内，CPU 中只有一部分位在 0 和 1 之间转换。 不同的工作负载表现出不同的切换率。 这导致方程中的应用比率 (AR) 值调节有功功率。 例如，某些类型的工作负载通常不执行浮点数学。 在这些工作负载中，浮点逻辑未使用，不会转换并消耗有功功率。

漏电可以被认为是 CPU 内部为了保持晶体管通电而损失的电荷。 漏电功率的方程比有功功率的方程更复杂，但从概念上讲它很简单：漏电功率随电压和温度呈指数增加。

漏电和动态功耗之间的细分对工作负载、处理器、进程生成和操作条件非常敏感。 动态功率通常占 CPU 功率的较大比例，特别是当处理器以高利用率运行时。

2、I/O Power

当今 CPU 设计中常见的高带宽互连可以贡献很大一部分 CPU 功率。 在新兴的低功耗微服务器领域尤其如此。 在其中一些产品中，I/O 设备消耗的功耗在 SoC 整体功耗中所占的比例往往更大。从概念上讲，I/O 设备有两种类型：那些以与其传输的带宽量成正比的方式消耗功率的设备 (DDR)，以及那些在唤醒时几乎消耗恒定功率的设备（PCIe/QPI）。

I/O 接口也具有有源功率和漏电功率，但将它们分开以进行电源管理讨论很有用。 传统 I/O 接口中的切换速率与流经该互连的数据带宽成正比。为了以非常高的频率传输数据，许多现代 I/O 设备已转向差分信号传输。 一对物理线路用于传输一条信息。 除了使用多条线路传输一位数据之外，这些通道的协议通常还设计为频繁且连续地切换，以提高信号完整性。 因此，即使在利用率较低的情况下，位也会继续切换，从而使功率对带宽基本上不敏感。

3、频率、电压和温度

虽然功率可以很容易地被认为是电压、频率和温度的函数，但这些组件中的每一个都会对其他组件的行为方式产生影响。 因此，它们之间的相互作用也与能源效率有关。

为了提高系统的频率，还必须提高电压。 运行电路所需的电压往往会随着频率的平方而增加（如下图）。 这种关系对于电源效率和理解电源管理至关重要。 在某些低频下，可以改变频率，而对电压的影响很小（如果有的话），并且总功率的增加相对较小。 在较高频率下，需要大幅增加电压才能获得小幅频率增加。 这两个组件之间的确切关系基于晶体管设计。 有多种制造和设计技术用于选择不同频率点的工作电压。 因此，尽管从概念上讲电压与频率的平方成正比，但这并不总是实际系统在生产中的运行方式。

不同的晶体管设计和工艺技术具有不同的特性。 可以实现更高频率的晶体管必须权衡低功耗特性。 这些通常用于高功率服务器 CPU 设计。 另一方面，晶体管可以针对低漏电和低功耗运行进行优化，权衡高变频运行。 这种类型的晶体管用于手机、平板电脑和笔记本电脑设备。 它们还可以用于微服务器和其他低功耗服务器。 这两种类型的晶体管都可用于构建高能效的 CPU 和数据中心。

[!NOTE]

以较低的电压和频率（和功率）执行并不一定会使系统更加节能。 相反，最有效的工作点往往存在于指数曲线的“拐点”周围（或稍微位于拐点右侧）。 一个常见的误解是频率越低、功率越低，运行效率就越高。 这通常是不正确的，尤其是在墙上测量功率时。 还可以使用利用功率优化晶体管的低功率 CPU 和基于频率优化晶体管的高功率 CPU 来构建非常节能的数据中心。

漏电流对温度呈指数敏感性。 传统上，温度升高会导致泄漏电流增加，从而导致更高的功率。 然而，在最近几代工艺中，泄漏功率呈下降趋势。 结果是对温度的敏感性降低。

还有另一种现象称为逆温度依赖性inverse temperature dependence（ITD）。 随着温度下降，晶体管在给定频率下运行所需的电压会增加。 这种行为在较低电压下最为明显。 在高功率服务器 CPU 中，这种现象通常不会影响峰值性能或功率，因为这些情况下的电压和温度足够高，即使需要任何 ITD 补偿，也很少。 然而，ITD 对于在较低电压、频率和温度下运行的低功耗 CPU 来说可能变得更加重要。 ITD 现象早已为人所知，但随着泄漏功率的降低，ITD 现象可能会变得更加引人注目。 从历史上看，随着温度降低，泄漏功率下降的幅度大于 ITD 功率增加的幅度。 对于泄漏功率水平非常低的产品，ITD 效应可能会导致低温下的净功率增加。

二、CPU的节能技术

前面我们已经简要解释了CPU功耗的基础知识，现在我们来看一些实现CPU电源效率的高级技术。 有两种概念性的省电方法：

• Turn it off. （关闭）
• Turn it down.（调低/降低）

1、Turn It Off

关掉家里的灯是一种非常有效的省电方法。 荧光灯泡首次引入市场时，许多人对它需要很长时间才能达到所需的光量感到不满。 在 CPU 中，也会出现类似的问题。 “关闭”有不同的级别（如下图），需要在节能和不同子组件在需要时可用的速度之间进行权衡。

时钟门控（Clock gating）

现代 CPU 中使用的同步设计取决于在整个逻辑中路由的时钟。 如果未使用给定的逻辑块，则不需要驱动进入该逻辑的时钟。 时钟门控是停止给定逻辑块的时钟以节省功耗的行为。 通过门控时钟，可以节省时钟本身的功率，以及逻辑中的任何其他动态功率（因为没有时钟就无法转换）。

时钟门控可以在很宽的粒度范围内执行。 例如，如果不使用单个加法器，则可以对其进行时钟门控，或者可以对整个内核进行时钟门控。 当硬件检测到逻辑未使用时，时钟门控可以自主执行，也可以通过软件干预来执行。 当逻辑块的时钟被门控时，该块的动态功率被降低到接近于零，而泄漏功率不受影响。 电路中的状态（信息）得以维持。

电源门控（Power gating）

电源门控是一种可以节省漏电和有功功率的技术。 然而，与时钟门控相比，唤醒电路需要更长的时间。 除了防止晶体管状态转换之外，电源门控还可以消除电路中的所有电源，从而使漏电功率也降至零。 电源门控会导致状态丢失，因此特殊操作（如保存/恢复或保留触发器）必须与电源门控结合使用。

2、Turn It Down

电压对电路的动态功率和漏电功率都有显着影响。 通过在不需要性能时降低电压，从而达到可以节省电力的目的。 下图总结了两种常见的降低电压的机制。

[!NOTE]

降低电压是节能的关键部分。 漏电功率与电压成指数关系，动态功率与电压的平方成关系。

三、CPU的节能机制

电源管理算法的一项主要挑战是了解多种算法将如何相互影响。 节省电力需要付出一定的成本。 例如，如果将内存置于低功耗状态，则需要时间将其唤醒才能满足内存请求。 当该请求等待内存唤醒时，系统中的其他部分通常会唤醒并等待，同时消耗能量。 如果刻意在系统的某一部分积极节能实际上可能会导致整个系统的净功率增加。 可以启用一些功能，以一定的总体性能成本为其子系统节省电力，并且总体节能程度最低甚至没有。 良好的系统设计将为最终用户隐藏这些挑战，并使他们能够充分利用系统。

平台特征在确定“什么是最好的”方面可以发挥重要作用。 例如，在跨两个插槽连接 1 TB 内存的系统中，很大一部分平台功耗都消耗在内存上。 在这里积极使用内存电源管理通常是一个好主意。 另一方面，如果系统只有 8 GB 内存和单个 DIMM 内存，则使用内存电源管理只能节省少量的整体内存功耗，并且在某些情况下可能会增加平台功耗，因为系统中的活动时间会增加。

1、竞争空闲(Race to Idle)

在驾驶汽车的时候，通常以80公里每小时左右的速度行驶时被认为是效率最高。 如果你开得比这个速度快，固定行程内汽车的活动时间就会缩短，活动时的效率就会降低，并且会消耗更多的汽油。 如果您开得较慢，汽油消耗的速度可能会较慢，但总的汽油消耗量会更大，因为汽车的活动时间更长。 当速度高于80公里每小时的时候，汽车的风阻和阻力会更高，并且发动机通常不会优化以高效运行。 在较低速度下，阻力可能较低，但发动机运行低于其能力，从而降低效率。

CPU 内部也可能存在类似的行为。 汽车的速度与CPU的电压/频率类似。 理论上，您可以通过在最高效的工作点之间循环并关闭它来实现最佳电源效率，以提供所需的性能水平。 这种策略传统上被称为“Race to Idle or Race to Halt“（HALT 是一条 CPU 指令，指示内核停止执行并进入省电状态）。

在许多服务器使用模型中，“竞争空闲(Race to Idle)” 策略通常被证明效率低下，因为空闲状态由于其限制而消耗过多的电量。 想象一下，每当您想使用汽车时，都需要一个小时才能启动它。 如果您全天频繁使用汽车，您永远不会关闭汽车。同样，有固定时间表的通勤者可能能够忍受早上花一小时打开汽车（因为他们可以有计划的在准备上班之前打开汽车）。 这是因为他们知道什么时候需要它。 而“随叫随到”的医生则无法容忍这种情况，因为他们可能需要随时上班，对延误零容忍。

服务器往往更像是值班医生。 他们永远不知道什么时候会需要他们，并且需要在”被需要“时迅速提供帮助。 如果采用需要较长退出延迟的深度空闲状态，则可能会出现网络数据包丢失等问题。

2、CPU 功率和性能状态

存在多种用于关闭逻辑以及降低 CPU 内部工作电压的标准技术。 接下来讲一讲CPU 中存在的电源管理功能，然后详细介绍每种状态在不同环境下的执行情况。下表展示了不同电源管理状态的概述。

State	Granularity	Description
C-states	Core/thread	Turning cores off and halting execution of instructions: These states save power by stopping execution on the core. Different levels of C-state exist with varied amounts of power savings and exit latency costs. C1 is the state with the shortest exit latency but least power savings. Larger numbers, like C6, imply deeper power savings and longer exit latencies.
Package C-states	Package	Turning off a subset of the package to save power when it is idle: Package C-states kick in when all cores are in a C-state other than C0 (active). Like with core C-states, there can be multiple levels of package C-states that provide tradeoffs between power savings and exit latency. The package includes all the cores as well as other package blocks, such as shared caches, integrated PCIe, memory controllers, and so on. On Intel Xeon CPUs, these states typically have exit latencies <40 ms in order to avoid network packet drops.
P-states	Various	Changing the frequency and voltage of a subset of the system: Traditionally these states have been focused on the cores, but changing the frequencies of other components of the CPU is also possible (such as a shared L3 cache). Execution can continue at varied performance and power levels when using P-states.
T-states	Core	Duty cycling the cores at a fixed interval: T-states duty cycle the core execution to save additional power. These states are generally used for aggressive throttling when needed for thermal, electrical, or power reasons. They traditionally have not been used for power efficiency.
S-states	Package	Turning off the entire package (sleep state): These states are most common in client and workstation usage models, but can also be applied in some server CPUs. They tend to have very long exit latencies (seconds) but can drive the power close to zero. S0 represents the active state and S5 the “off” state (with multiples states in between).
G-states	Platform	Global states: These states refer to the power state of the platform. These are similar to S-states. G-states are generally not visible to the end user and are used by platform designers.
D-states	Device	Devices (PCIe, SATA, etc.) in a powereddown state: D-states are traditionally for devices such as PCIe cards and SATA and refer to low-power states where the device is powered down. D-states are not a focus on servers.

3、C-States

C-states使软件能够通过关闭内核或其他逻辑来请求 CPU 进入低功耗状态。 如果单个 CPU 内核支持多线程 (SMT)，则它可以支持多个软件线程。 每个硬件线程都有自己的状态，并且有机会请求不同的 C 状态(C-states)。 这些被称为线程 C 状态(thread C-states)，并表示为 TCx。 为了使核心进入核心 C 状态（core C-state 表示为 CCx），该核心上的每个线程都必须请求该状态或更深的状态。 例如，在支持两个线程的核心上，如果任一线程位于 TC0 中，则该核心必须位于 CC0 中。 如果一个线程在TC3，另一个线程在TC6，那么该核心将被允许进入CC3。 线程 C 状态本身节省的电量最少，而核心 C 状态可以节省大量电量。

对于package C-states，当该package上的所有核心进入深度core state时可以进入这些状态。 这些状态通常表示为 PCx 或 PkgCx。 有时，包状态编号与该包上的核心状态相关，但这不是硬性规则。 例如，当某些现代服务器处理器上的所有内核都处于 CC3 或 CC6 状态但其他限制阻止系统进入比 PC2 更深的状态时，就会使用 PC2 状态。

4、Thread C-States

软件在线程粒度上请求 C 状态。 当线程进入线程 C 状态而不引发核心 C 状态时，将采取最小（如果有）节能操作。 在支持 SMT 的 CPU 上，这些状态实际上是进入核心 C 状态的垫脚石。 在不支持 SMT 的 CPU 上，线程和核心 C 状态实际上是相同的。

5、Core C-States

核心 C 状态(Core C-states)确定核心是打开还是关闭。 在正常执行情况下，核心处于 C0 状态。 当软件（通常是操作系统）指示逻辑处理器应该空闲时，它将进入 C 状态。 各种唤醒事件都可能触发内核再次开始执行代码（中断和计时器是常见的例子）。 软件向 CPU 提供关于它应该进入什么状态的提示。 MWAIT 指令告诉 CPU 进入 C 状态，其中包含有关所需状态的参数。 然而，CPU 电源管理子系统可以执行它认为最佳的任何状态（这称为 C 状态降级 C-state demotion）。

Core C-State	Wake Latency	Description
CC0	N/A	The active state (code executing): At least one thread is actively executing in this state. Autonomous clock gating is common for unused logic blocks.
CC1	~0.001 ms	Core clock gated: In CC1, the core clocks are (mostly) gated. Some clocks may still be active (for example, to service external snoops), but dynamic power is driven close to zero. Core caches and TLBs are maintained, coherent, and available.
CC1e	~0.001 ms + frequency transition	Enhanced C1—hint to drop voltage: CC1e is effectively the same as C1, except it provides a hint to the global voltage/frequency control that V/f can be reduced to save additional power.
CC3	~0.05–0.1 ms	Clocks gated and request for retention voltage: Processor state is maintained, but voltage is allowed to drop to Vret. L1 + L2 (core) caches are flushed. Core TLBs are flushed.
CC6	~0.05–0.1 ms	Power gating: The core is power gated (voltage at 0). L1 + L2 (core) caches are flushed. Core TLBs are flushed. Processor state is saved outside the core (and restored on a wake).
CC7–CC10	Various	CC6 with extra savings outside the core: Additional states deeper than CC6 exist on certain CPUs. These states are generally not supported on server processors today due to their long latencies.

5.1、Core C0

Core C0 (CC0) 是核心执行一个或多个线程时的活动状态。 核心的缓存全部可用。 然而，在活跃状态下，CPU中的某些逻辑单元可能没有被使用，这时就需要使用自主时钟门控技术。自主时钟门控是一种常见的技术，用于关闭未使用的逻辑单元的时钟，以降低功耗。逻辑单元通常由多个逻辑块组成，其中一些块在活跃状态下不被使用。通过自主时钟门控技术，这些未使用的逻辑块可以被自动关闭，从而减少功耗的消耗。这种技术基于CPU内部的智能机制，根据线程的活动情况和逻辑单元的使用情况来自动控制时钟信号。自主时钟门控技术的应用可以在不影响性能的前提下，降低CPU的功耗。例如，当进行整型运算指令时，浮点运算的逻辑部分就可以进行时钟门控。

5.2、Core C1 and C1e

Core C1 (CC1) 是具有最快退出延迟的核心睡眠状态。 时钟门控在大部分逻辑上执行，但所有核心状态均得到维护（高速缓存、TLB 等）。 一些逻辑通常仍然处于活动状态以支持对核心高速缓存的窥探以保持一致性。 CC1是核心可以在不与PCU交互的情况下进入和退出的状态。 这可以实现快速转换，但也会阻止全局电源管理算法利用此状态进行某些优化。CC1唤醒延时大约为1us，睡得最轻醒得最快的一个休眠状态，Core的大部分时钟信号被门控，一些时钟信号可能仍处于活动状态（例如，为了处理外部的snoop操作），但动态功耗接近零（因为晶体管不再翻转）。在CC1状态下，核心的缓存和TLB（转换后备缓冲）仍然保持有效、一致，并可供使用。CC1状态不需要和CPU的PCU交互就可以进入，这样保证了很低的唤醒延时，但是也失去了一些全局电源管理优化的空间。

Core C1e (CC1e)是与CC1类似的状态，只不过它提供了核心也可以降低到较低电压/频率的提示。 尽管从 C1 和 C1e 退出的延迟大致相同，但在唤醒后将内核恢复到请求的频率确实需要一些时间。 C1e状态通常是在packate粒度上实现的。 换句话说，在降低任何请求 C1e 的核心上的电压/频率之前，插槽上的所有核心必须首先进入 C1e 或更深层的状态。CC1e唤醒延时大约为1us 加上频率切换，CC1e在CC1的基础上，进一步增加了一个重要的提醒（hint），就是电压可以降，全局的电压频率可以进行调整，以进一步节省额外的功耗。从这个角度上来说，CC1e更像是一个package 级别的状态，因为它的好处在于电压和频率的调整，这个调整时全局的，也就意味着需要所有的core都进入CC1e甚至更深的睡眠状态。

5.3、Core C3

Core C3 (CC3) 提供门控时钟和将电压降至保持电压的请求。 从概念上讲，它是 C1e 的较低电压版本，不需要频率转换。 然而，CC3 确实会刷新核心缓存和核心 TLB。 它的唤醒延迟也比 C1e 长得多。 CC3唤醒延时大约为50~100us。这时候有点进入浅度睡眠的状态了。在这个状态下，门控时钟，并且把电压调低到保持的水平。CC3有点像是一个低电压水平的C1e，但是它不会调整频率。但是在CC3的时候开始做梦了，它把cache和TLB都清除了。CC3 的进入和退出与 PCU 协调，因此额外的优化可以进一步利用此状态。这也意味着可以有更多的优化策略，毕竟PCU作为一个全局的管家，可以整体协调更多的事情。

5.4、Core C6

Core C6 (CC6) 通过对核心进行电源门控来节省大量电量。 这需要核心刷新其状态，包括其缓存和 TLB。 核心 C6 的唤醒延迟比 CC3 更长（通常是两倍），因为它必须重新锁定 PLL 并取消电源门控，但它也可以比 CC3 或 C1e 节省更多的功耗（具体数量因产品而异）。 CC6是内核本身可能达到的最深的节能状态。

[!NOTE]

CC6 是服务器上的主力，可大幅节省闲置功耗。 CC1 对于在短空闲期间或在延迟要求不允许使用 CC6 的系统上节省电量非常有用。 CC3 状态在服务器实践中通常显示出最小的价值。 由于缓存刷新，此状态对性能的影响与 CC6 类似，并且仅当电压域中的所有核心都同意这样做时才会将电压降至 Vret。

5.5、Core C7 (and up)

比 CC6 更深的状态已在许多客户端设备上产品化。 内核本身没有任何比电源门控和 CC6 更深的状态，但这些更深的状态可以由软件请求，并且它们向全局电源管理算法提供有关封装范围电源管理优化潜力的提示（就像刷新共享 L3 缓存）。

[!NOTE]

比 CC6 更深的状态通常在服务器上受到挑战，因为服务器软件环境很少变得完全闲置。 例如，刷新 L3 缓存会产生不小的内存能量成本（在进入和唤醒时），并且还会导致短唤醒事件的唤醒周期更长（因为所有数据/代码必须从内存中获取）。 这些额外的电力成本往往会显著抵消（甚至超过）刷新缓存所节省的电力。 服务器的延迟容忍度也往往较低，这使得进一步的优化具有挑战性。

5.6、C-State Demotion

如果 PCU 认为操作系统正在请求次优状态，则 PCU 可以降级软件发出的 C 状态请求，并决定进入更浅的状态。 软件 C 状态控制的早期版本有时会在启用 C 状态时提出过于激进的请求，从而使某些客户面临 C 状态性能下降的问题。 为了解决这些问题，PCU 固件中添加了 C 状态降级，以防止在处理器确定可能损害性能或功效时进入深度 C 状态。 这些算法的细节并未公开，并且不同的算法已部署在不同的产品代上。 尽管 PCU 一直致力于减少 C 状态性能下降的风险，但操作系统也调整了其选择算法以减少自身的性能下降风险。 核心 C 状态的早期实现需要操作系统软件保存和恢复时间戳计数器 (TSC) 和本地 APIC 计时器。 最新的处理器已经取消了这一要求，进入 C 状态和唤醒备份的大部分工作都由 CPU 硬件和固件自主处理。

6、Package C-States

CPU的package是一个更大的概念，包含了core和uncore部分。因此在介绍完core C-state之后，我们才可以看整个CPU的package是如何根据每个core的C-state状态来对package的C-state进行设定。

当整个CPU变得闲得发慌的时候，它可以进入C状态（Package C-state）来省电，比单独各个组件节能的机制会更加省电！这些状态主要是针对CPU处于空闲或者接近空闲的情况设计的。具体每个CPU和不同代的CPU在定义这些Package状态时会有所不同，但是基本概念是一样的。当CPU陷入深度的Package C-state时，与CPU连接的设备（比如网络卡）将无法访问内存。为了让PCIe设备重新连接到主内存，英特尔服务器通常设定了一个最长的等待时间，大概是40微秒，这样就能保证设备的数据通道畅通无阻啦。所以说，Package C-state就像是CPU的一种”能省则省”的模式，让整个处理器在空闲时能够更加聪明地省电。虽然每个CPU都有自己的规矩，但是这个高层概念是通用的，就好像是大家都在追求省钱一样。下表展示了package C-state状态定义的示例。

Package C-State	Core C-States	Path to Memory	Description
PC0	At least one in CC0.	Available	The active state (code executing). No package-scoped power savings.
PC1e	None in CC0/ CC1. At least one in CC1e.	Available	All cores have entered C1e or deeper states, allowing the opportunity for the voltage and frequency to drop. At least one core is still in C1e, preventing more aggressive power savings.
PC2	All cores in CC3/CC6.	Available	All cores are in CC3/CC6, but PCIe or a remote socket is still active. The shared uncore must still be active to support these other traffic sources. Minimal package-scoped optimizations can be performed here. The actions in this state are effectively identical to PC1e.
PC3	All cores in CC3/ CC6. At least one in CC3.	Not available	All cores are in CC3/CC6 and other traffic sources (PCIe and remote sockets) are also idle. Package scoped operations, such as deep memory self-refresh or uncore Vret are possible.
PC6	All cores in CC6.	Not available	Same as PC3, except no cores are in CC3. Additional more aggressive power savings may be possible. On Ivy Bridge EP, for example, the L3 cache was only taken to retention voltage in PC6 and not in PC3.
PC7	All cores in CC7.	Not available	Same as PC6, except the L3 cache is also flushed.

[!NOTE]

PC7状态尚未在许多服务器处理器中产品化。 刷新 L3 缓存会消耗内存能量，并且还会导致任何短期核心唤醒时间显着延长，因为所有数据/代码都必须从内存中获取。 这些增加的成本往往会显着降低在这种状态下可以实现的节能效果，同时也会给用户带来更长的唤醒延迟。

Package C-state和Core C-state的关系

具体到每个CPU，和不同代的CPU定义Package C-state的状态会有所不同。我们用以下两张图为例，对常用的定义状态做一个说明。

7、P-States

P-states的发明是为了动态降低（或增加）CPU 工作电压和频率，以满足用户在给定时间点的需求。 以较低频率运行会导致性能较低，并且完成相同工作量时的延迟较长。 然而，用较低的能量完成所需的工作量是可能的。 一个很好的例子是运行新闻网站的 Web 服务器。 凌晨 3:00，不太可能有很多人访问该网络服务器上的数据。 通过以较低的电压/频率运行，可以节省电力。 该 CPU 上的每个 Web 请求事务将需要更长的时间才能完成，但在许多情况下，延迟增量相对于网络传输延迟来说非常小，以至于客户永远不会注意到。 当系统负载开始增加时，可以增加频率以满足更高水平的需求，同时保持持续的服务质量。 传统上，操作系统负责选择系统运行的频率。

[!NOTE]

如前面的图片 ”Voltage/frequency relationships“ 所示，频率降低所节省的电压在频率较低时会缩小（最终为零）。 将频率降低到超过电压缩放点是可能的，但效率往往较低。 用户此时最好使用 C 状态来节省电量。 因此，处理器具有支持的最低工作频率（称为 Pn），并且可能不会向操作系统暴露较低的频率或允许请求较低的频率。

简单来说，P-States对应了CPU在执行指令时的不同性能水平，也就是你在上班的时候的不同的精神状态：是高度集中的烧脑时刻，还是昏昏欲睡的摸鱼状态。但是，它并没有睡着，因此所有的P-State都对应了CPU的C0状态。CPU的P-States对应了一对电压和频率的组合，以此来提高或者降低CPU的性能水平。同样的工作，CPU的频率越低，也就意味着完成工作所需要的时间更长，自然这个时候的性能是较差的水平。然而，这也意味着，所消耗的能量也相应会低一些。

以Intel CPU为例，P-states 主要定义如下

• P01 - P01是最大的1核心Turbo频率，一个核心活跃时可以达到的最大频率。
• P0n - P0n是全核心涡轮增压频率范围。Turbo频率的高低取决于工作负荷和操作环境。Turbo是机会主义的，因为达到的频率可能低于最大频率。
• P1 - P1是SKU的保证基频。在标准工作条件下，所有核心都可以以这种速度运行。这有时被称为P1n。
• P2, P3和所有较低的P状态被定义为低于前一个P状态频率100 MHz(称为“bin”)。
• Pn 是CPU支持的最低p状态。

[!NOTE]

• C-states和 P-states都属于 CPU 节能机制，CPU 会在不同工况下进入这些机制。权衡的结果是，当再次需要用到 CPU 时，退出这些状态的时间会稍微长一点。
• C-states = idle state
• P-states = Performance State
• 所有的P-State都对应了CPU的C0状态
• C-states和 P-states都是通过调整 CPU 时钟频率和电压来降低功耗

8、简要总结

8.1、状态总结

• Core C-states:

  • Available States: C0, C1, C1E, C6.
  • C0 is the active state where instructions are executed. No instructions are executed in other Core C-states.
  • Lower C-states (C6 being the lowest) are power optimized, resulting in greater power savings and higher exit latency.
  • If a core reaches C6, the L1 and L2 Caches are flushed to L3 Cache, and data may need to be reloaded into cache after the core exits the power-optimized state.

• Package C-states:

  • Available States: PC0, PC1E, PC2, PC6.
  • PC0 is the active state where one or more cores is actively executing instructions. All other PC-states require all cores to be in C6.
  • Lower PC-states (PC6 being the lowest) result in greater power savings and higher exit latency.
  • All PC-states except PC6 still allow snoop, memory, and other traffic to cross the CPU. If a snoop request comes in while the CPU is in PC6, it wakes and moves to PC2 to service the request.

• P-states:

  • P01 is the Max 1 Core Turbo Frequency, the maximum frequency that can be reached with one core active.

  • P0n is the All Core Turbo Boost Frequency range. The level of Turbo Frequency depends on the workload and the operating environment. Turbo is opportunistic as the frequency achieved may fall short of the maximum frequency.

  • P1 is the Guaranteed Base Frequency of a SKU. All cores can run at this speed while within standard operating conditions.

    This is sometimes referred to as P1n.

  • P2, P3, and all lower P-states are defined as 100 MHz (referred to as a ‘bin’) below the previous P-state’s frequency.

  • Pn is the lowest P-state supported by the CPU.

8.2、状态管理

C-states管理

Hardware: 在某些配置中，CPU 中的电源控制单元 (PCU) 负责自主协调Core和Packate的 C 状态，而 BIOS 配置允许您限制平台可用的 C 状态，确保它永远不会低于所需的 C 状态。 状态。 或者，intel_idle 和 Linux 调度程序管理 C 状态。

Operating System: 核心 C 状态由操作系统控制，如 ACPI 规范所定义。 操作系统可以使用 MWAIT 和 MONITOR 指令告诉内核中的线程进入特定的 C 状态。 在支持的 CPU 中，应用软件可以使用 waitpkg 指令来请求功耗优化状态 C0.1 和 C0.2。

Orchestration: 不适用。

Application: 没有直接的应用程序级 C 状态进入/退出控制。 软件技术可用于影响 C 状态的内核控制。

P-states管理

Hardware: 在英特尔至强可扩展处理器中，硬件控制性能状态 (HWP) 提供将 P 状态控制传递给硬件的选项，使其能够根据每个内核的负载和操作系统对频率和电压进行更快、更精细的调整 提示。 如果没有 HWP，操作系统可以直接通过 intel_pstate 驱动程序或 acpi_cpufreq 驱动程序请求 P 状态。

Operating System: P 状态可以通过 Linux 内核系统文件系统“sysfs”从用户空间进行管理。 默认情况下，P 状态有一个称为调节器的管理例程，它决定如何控制频率以响应工作负载。

Orchestration: 不适用。

DPDK Application: DPDK 电源管理库允许用户空间应用程序通过动态调整 CPU 频率来节省电量。 librte_power API 可用于从内核请求特定的 P 状态配置。 此外，轮询模式驱动程序还支持频率缩放。

四、Linux CPU C-States管理

在 Linux 操作系统上，处理器 C 状态通过空闲任务和 CPUIdle 子系统进行管理。 当CPU无事可做时，Linux会为CPU分配特殊的“空闲”任务来进行CPU空闲时间管理。 CPU 随后被视为空闲。 “空闲”任务也称为空闲循环，因为当没有其他任务运行时，它会重复寻找机会将空闲 CPU 置于深度睡眠状态。 它借助CPUIdle子系统完成睡眠状态的进入。

1、Idle Task

空闲任务（Idle Task）是一个死循环。 在每个循环周期中，它首先检查是否有其他进程需要调度运行。 如果有，则调用调度器进行任务调度。 如果没有，则调用 CPUIdle 子系统选择适合当前CPU运行状态的睡眠状态，然后调用CPUIdle子系统驱动CPU进入选择的睡眠状态。 当接收到中断时，系统退出睡眠状态并开始处理中断。 中断可能来自另一个 CPU，并由调度程序触发，因为空闲 CPU 需要处理新任务。 中断可能是由于已完成的 IO 命令或调度程序造成的。 中断处理后，空闲任务恢复运行睡眠状态进入调用后的指令。 它会重新检查可能的重新安排。 因此另一个循环开始。

2、CPUIdle Subsystem

睡眠状态的进入是由空闲任务发起的，因为只有空闲任务知道系统何时进入空闲状态。 但它不知道什么睡眠状态最适合当前系统运行状态，以及如何让系统进入睡眠状态。 所有这些问题都由 CPUIdle 子系统解决。 CPUIdle子系统由CPUIdle核心、CPUIdle驱动程序和CPUIdle调控器组成，如下图所示。 CPUIdle 调节器会找到最适合当前情况的睡眠状态。 CPUIdle驱动程序负责C状态枚举和进入。

这将空闲任务与睡眠状态选择的职责以及底层 CPU 硬件的细节和变化隔离开来。 但仍然需要修改空闲任务以支持新的Governors或驱动程序。CPUIdle 核心被设计为一个框架，用于解耦空闲任务与调控器和驱动程序之间的硬编码互连。 它为空闲任务、调控器和驱动程序提供了一个统一且抽象的接口。空闲任务调用CPUIdle核心接口来选择睡眠状态并执行它，而无需直接接触调速器和驱动程序。 仅当接口稳定时，这才能使空闲任务与 CPUIdle 子系统实现修改隔离。Governors和驱动程序也从框架设计中受益。 每个人都可以专注于实现框架定义的接口函数，而不需要了解空闲任务以及它将如何使用它们。

3、CPUIdle Governors

与 CPUidle 驱动程序不同，CPUIdle 调控器(Governors)是平台中立的。 它们使用驱动程序提供的抽象 C 状态数组（其中包含所有平台通用的数据）来进行 C 状态选择。CPU 的最佳 C 状态是能够节省最大功率且延迟可接受的状态。 每个 C-State 都有一个目标驻留时间，即 CPU 预计停留在 C 状态的最短时间。 此外，PM QoS 还需要满足可调整的 CPU 延迟要求，这意味着 C 状态退出延迟不应超过 CPU 延迟要求。 通常，C 状态越深，其目标驻留和退出延迟就越长。 因此，调控器选择最深的 C 状态，目标驻留时间小于 CPU 空闲时间，退出延迟小于 CPU 延迟要求。然而，CPU 空闲时间不可用，因此调控器必须对其进行预测。 调控器可以使用许多因素进行预测。 其中，有两个时间因素最为重要：

• 从当前时间到调用调控器选择 C 状态时最近的计时器事件的时间段。 它是CPU可以处于空闲状态的最长时间，涵盖了进入和退出空闲状态所需的时间。 然而，CPU 随时可能被非定时器事件唤醒。

• 当 CPU 退出选定的 C 状态时，CPU 保持空闲的时间段。 调速器可以将其与最接近的计时器的时间一起使用来预测未来的空闲持续时间。

调控器如何执行预测取决于它使用的算法，这是拥有多个调控器的主要原因。有以下四个可用的调控器，Haltpoll 的特殊之处在于它是针对虚拟化的。 只能有一名处于活动状态的调控器，但可以根据需要进行更改。调控器只需向核心注册即可使其可用。 一次只能使用一个调控器。 如果有多个调控器注册，则评级最高的调控器处于活动状态。

• menu
• ladder
• TEO
• haltpoll

4、CPUIdle Drivers

CPUIdle 驱动程序首先从底层硬件或固件获取 C 状态信息，并将 C 状态保存在线性数组中。 C-state数组元素记录了C-state的名称、功耗、进入和退出的延迟、如何进入和退出等。数组中的元素按照功耗降序排列。准备好 C 状态数组后，驱动程序将自身注册到 CPUIdle 内核，并将 C 状态数组传递给内核。 内核将使用第一个注册的驱动程序作为当前驱动程序来驱动 C 状态。 也就是说，最多有一个活跃的驱动程序，并且活跃的驱动程序一旦分配就不能更改。最后，驱动程序将 CPU 注册为 CPUIdle 内核的 CPUIdle 设备。 此后，CPU 就准备好进行 C 状态管理。目前，有两个驱动程序可用于x86平台:

• acpi_idle, which supports ACPI C-States and is supported on Intel and AMD processors
• intel_idle, which supports MWAIT C-States and is supported only on Intel processors

intel_idle 被硬编码为在 acpi_idle 之前注册。 因此，如果Intel平台同时支持ACPI和MWAIT C状态，则将使用intel_idle。 当平台仅支持 ACPI Cstate 或 intel_idle 驱动程序被禁用时，使用 acpi_idle。

5、Managing Linux Processor C-States

Linux 提供了多种方法来管理 CPU C 状态和 CPUIdle 子系统本身。 使用它们，我们可以定制系统以最适合应用程序环境。 CPUIdle 子系统的大部分信息通过 sysfs 作为目录下的文件公开
/sys/devices/system/cpu/cpuidle/.

可用的调控器可以从文件 available_governors 中读取。 当前使用的gorvernor的名称可以从current_governor_ro或current_governor中读取。 后者也可用于切换调控器：将调控器的名称写入 current_governor 会将当前使用的调控器切换到它。 当前使用的驱动程序的名称可以从 current_driver 中读取。 对于每个CPU n，都有一个sysfs目录/sys/devices/system/cpu/cpun/cpuidle/，其中包含一组与CPU n的C状态相对应的子目录“statei”。 每个子目录包含几个代表 C 状态属性的文件：

• desc：C 状态的描述。
• disable：C 状态是否禁用。
• latency：C 状态的退出延迟（以微秒为单位）。
• name：C 状态的名称。
• power：C 状态下硬件消耗的功率（如果指定）以毫瓦为单位； 否则为 0。
• residency：C 状态的目标驻留（以微秒为单位）。
• time：给定 CPU 在 C 状态下花费的总时间（由内核测量），以微秒为单位。
• usage：给定 CPU 要求硬件进入 C 状态的总次数。

在属性文件中，disable 是唯一可写的。 如果它包含 1，则对于该特定 CPU 禁用给定的 C 状态，这意味着调控器永远不会为该 CPU 选择它，因此 CPU 永远不会进入 C 状态。 如果disable包含0，则给定的C状态已准备好可供CPU选择和进入。 禁用是针对每个 CPU 的，即针对一个 CPU 的设置不会影响其他 CPU 的 C 状态使用。 Cpupower 是执行各种电源管理工作的 Linux 实用程序。 它有两个用于 C 状态管理的子命令。

• cpupoweridle-info 子命令从 sysfs 检索并输出 CPUIdle 子系统信息。 这是一次性转储 CPUIdle 子系统信息的一种便捷方法。

# cpupower idle-info
CPUidle driver: intel_idle
CPUidle governor: menu
analyzing CPU 0:
Number of idle states: 4
Available idle states: POLL C1 C1E C6
POLL:
Flags/Description: CPUIDLE CORE POLL IDLE
Latency: 0
Usage: 39
Duration: 2036
C1:
Flags/Description: MWAIT 0x00
Latency: 1
Usage: 401
Duration: 176878
C1E:
Flags/Description: MWAIT 0x01
Latency: 4
Usage: 12648
Duration: 1373816
C6:
Flags/Description: MWAIT 0x20
Latency: 170
Usage: 18540
Duration: 112338563

• cpupoweridle-set 子命令可用于禁用/启用 C 状态。 由于该子命令可以批量处理多个CPU，因此它使我们摆脱了逐一写入禁用sysfs文件的负担。

禁用 cpulist 中 CPU 的第 n 个 C 状态：

cpupower idle-set -c cpulist -d n

启用 cpulist 中 CPU 的第 n 个 C 状态：

cpupower idle-set -c cpulist -e n

启用 cpulist 中 CPU 的所有 C 状态：

cpupower idle-set -c cpulist -E

请注意，如果选项 -c 未提供 cpulist，则设置所有 CPU。 子命令中的C状态编号是sysfs中C状态的序号，例如以下命令将禁用
/sys/devices/system/cpu/cpu0/cpuidle/state2：

cpupower idle-set -c 0 -d 2

6、Kernel Command Line Parameters

相较于正常的 C 状态控制，Linux 允许用户使用内核命令行参数配置 CPUIdle 子系统级别设置。共有四个内核参数控制空闲子系统不同部分的可用性。 “•” 表示启用了某个内核参数或模块，“°” 表示未启用，“-” 表示无关紧要。

• intel_idle.max_cstate=n 将 intel_idle 支持的 C 状态限制为 C0、C1、…、Cn。 如果设置为 0，则禁用 intel_idle 驱动程序。
• processor.max_cstate 与 intel_idle.max_cstate类似, 但它用于 acpi_idle 驱动程序。 将processor.max_cstate设置为0不会禁用acpi_idle； 相反，acpi_idle 将其视为processor.max_cstate=1。
• cpuidle.off=1 禁用 CPUIdle 子系统。 禁用的 CPUIdle 核心不接受来自调控器和驱动程序的新注册。 因此，这实际上使所有调控器和驱动程序失效。

然而，上述内核参数都不会阻止系统进入 C1 状态。 这是因为，如果 CPUIdle 功能不可用，空闲任务会尝试默认的 CPU 空闲例程(CPU idle routine)，该例程特定于 CPU 架构。 对于x86，默认的CPU空闲例程是执行MWAIT或HLT指令，这将使CPU进入C1。 由于 MWAIT 比 HLT 更高效，因此默认 CPU 空闲例程更喜欢 MWAIT 而不是 HLT，并且仅当 MWAIT 不可用时才使用 HLT。 自 Linux 6.0版本内核起，默认的 CPU 空闲例程也支持 AMD 处理器的 MWAIT。因此，要完全禁用 C 状态，还需要禁用默认的 CPU 空闲例程。 这可以通过内核参数idle=…来完成。 它只针对于 x86 平台并提供三个有效参数。

• idle=poll: 禁用 CPUIdle 驱动程序和默认的 CPU 空闲例程。 空闲任务被迫运行轮询空闲循环。
• idle=halt: 禁用 CPUIdle 驱动程序，并且 HALT 被强制用于 CPU 空闲循环。
• idle=nowait: 禁用 CPU C 状态的 MWAIT，从而禁用 intel_idle 驱动程序。

因此，“idle=poll” 将禁用 Linux 上的所有 C 状态。

五、配置案例

对于一台服务器而言，通常C-States默认就是开启的，但在实际使用中出于各种原因有可能需要关闭C-States，例如运行基准测试，或者用户需要CPU始终保持最高频率运行，或者对于高性能网卡的实时性能要求极高的场景（100G/200G网卡）再或者为了解决某些问题/故障以保证系统的稳定性。根据上面的讲解可以确定要完全关闭C-states，就需要在系统平台层面和操作系统层面同步设置才能达到最理想的效果。以下分别演示了如何在基于Intel CPU和基于 AMD CPU的 ThinkSystem服务器上进行关闭C-State。

1、ThinkSystem Intel Platform Server

1.1、uEFI设定

1，在服务器平台层面关闭C-states需要进入uEFI配置界面完成，具体路径为：“System Settings –> Operating Modes”，将运行模式改为 “Custom Mode”，然后更改以下几项 :

• Processors.CStates=Disable
• Processors.C1EnhancedMode=Disable
• Processors.MONITORMWAIT=Disable

2，对于Package C-state，不同机型默认设置不同，有些默认就是关闭的，所以不需要做额外的操作。并且如果C-States和C1EnhancedMode已经关闭，也不需要对Package C-state作额外修改。但是为了保险起见，可以通过以下方式来检查Package C-state状态。uEFI配置菜单中没有Package C-state项，需要使用OneCli工具来检查或设置Package C-state。

使用如下命令检查Package C-state状态:

OneCli.exe config show Processors.PackageCstate --bmc XCC_USERID:XCC_PASSW0RD@XCC_IP --override

如果返回结果是“Disable”，表示Package C-state处于关闭状态。如果结果显示为“Enable”，表示Package C-state处于开启状态，则可以通过以下命令将Package C-state设置为“关闭”。

OneCli.exe config set Processors.PackageCstate "Disable" --bmc XCC_USERID:XCC_PASSW0RD@XCC_IP --override

[!NOTE]

需要注意的是，有些操作系统可能会对“MONITOR/MWAIT”有严重依赖以实现其自身的一些功能，例如如果使用了VMware EVC (Enhanced vMotion Compatibility), 则不能关闭 “MONITOR/MWAIT”。建议根据实际情况在关闭 “MONITOR/MWAIT”之前，向操作系统厂家做充足的咨询和确认。

1.2、OS设定（以Linux为例）

在Linux系统中，CPUidle默认是启用的，并且它会覆盖BIOS/uEFI设置。所以只在uEFI中做相关的修改无法起到期望的效果。为了确保C-States在OS中没有被启用，需要在kernel command line /boot/grub/grub.conf. 中添加 “intel_idle. max_cstate=0” ”idle=poll” (for Intel)。

[root@localhost ~]# vi /etc/default/grub
[root@localhost ~]# cat /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="crashkernel=auto spectre_v2=retpoline rd.lvm.lv=centos/root rd.lvm.lv=centos/swap intel_idle.max_cstate=0 idle=poll rhgb quiet"
GRUB_DISABLE_RECOVERY="true"

[root@localhost ~]# grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.10.0-1160.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-1160.el7.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-f1666be298fb490e8260459de61f7496
Found initrd image: /boot/initramfs-0-rescue-f1666be298fb490e8260459de61f7496.img
Found Windows Boot Manager on /dev/sdb2@/EFI/Microsoft/Boot/bootmgfw.efi
done

[root@localhost ~]# reboot

RHEL：

• RHEL6及以前版本： 编辑/boot/grub/grub.conf 添加 “intel_idle.max_cstate=0“
• RHEL7及更高版本：编辑/etc/sysconfig/grub 添加 “intel_idle.max_cstate=0“

SLES:

• 编辑 /boot/grub/menu. lst 添加 ”intel_idle. max_cstate=0“

1.3、场景总结

• UEFI settings enabled, with no custom boot options then the intel_idle C-State driver is used
• UEFI settings enabled, intel_idle.max_C-State=0 then acpi_idle C-State driver is used
• UEFI settings enabled, intel_idle.max_C-State=0 and acpi_idle.max_C-State=0 (or 1) then C-States disabled in Linux
• UEFI settings disabled, with no custom boot settings then intel_idle C-State driver is used
• UEFI settings disabled, acpi_idle.max_C-State=0 (or 1) then intel_idle C-State driver is used
• UEFI settings disabled, intel_idle.max_C-State=0 then C-States disabled in Linux

2、ThinkSystem AMD Platform Server

2.1、uEFI设定(SR635/SR655)

1，在服务器平台层面关闭C-states需要进入uEFI配置界面完成，具体路径为：“Advanced –> CPU Configuration –>Global C-state Control”。

• Bios.Q00056 Global C-state Control=Disabled

2.2、uEFI设定(SR645/SR665)

1，在服务器平台层面关闭C-states需要进入uEFI配置界面完成，具体路径为：“System Settings –> Operating Modes”，将运行模式改为 “Custom Mode”，然后更改以下几项 :

• Processors GlobalC-stateControl Disable
• Processors DF C-States Disable

2.3、uEFI设定(ThinkSystem AMD V3平台)

1，在服务器平台层面关闭C-states需要进入uEFI配置界面完成，具体路径为：“System Settings –> Operating Modes”，将运行模式改为 “Custom Mode”，然后更改以下几项 :

• Processors GlobalC-stateControl Disable
• Processors DF C-States Disable
• Processors MONITOR/MWAIT Disable

2.4、OS设定（以Linux为例）

相较于Intel CPU, 使用AMD CPU时需要在kernel command line /boot/grub/grub.conf. 中添加 “processor.max_cstate=0 idle=poll。

[root@localhost ~]# vi /etc/default/grub
[root@localhost ~]# cat /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="crashkernel=auto spectre_v2=retpoline rd.lvm.lv=centos/root rd.lvm.lv=centos/swap processor.max_cstate=0 idle=poll rhgb quiet"
GRUB_DISABLE_RECOVERY="true"

[root@localhost ~]# grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.10.0-1160.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-1160.el7.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-f1666be298fb490e8260459de61f7496
Found initrd image: /boot/initramfs-0-rescue-f1666be298fb490e8260459de61f7496.img
Found Windows Boot Manager on /dev/sdb2@/EFI/Microsoft/Boot/bootmgfw.efi
done

[root@localhost ~]# reboot

2.5、AMD服务器优化常用参数

下表总结了AMD服务器常用的kernel boot参数，通常这些参数用来做服务器优化使用，例如通过设置参数达到超低延时的要求，其中就包括C-States相关参数。注意这些参数需要按实际需要使用，或通过测试验证来确定哪些参数对需求有用。

Parameters	Description
idle=poll	forces a polling idle loop that can slightly improve the performance of waking up an idle CPU.
transparent_hugepage=never	This disables transparent_hugepages because managing transparent_hugepages can cause latency spikes when the kernel cannot find a contiguous 2M page, or the daemon is defragmenting and collapsing memory into one huge page in the background. If your application could benefit from huge pages, consider using static huge pages by configuring hugetlbfs. The memory allocations in your application need to be from heap memory to see the benefit of static huge pages.
audit=0	The Linux Audit system provides a way to track and log events that are happening on your system. This causes the kernel audit subsystem to be disabled and cannot be enabled until the next reboot.
selinux=0	This disables the Linux Security module that provides a mechanism for supporting access control security policies.
nmi_watchdog=0	This disables the nmi watchdog because it uses the Perf infrastructure. Perf is not intended to run as a continuous profiling utility, especially in low latency environments where it can cause spikes.
nohz=on	Disables the kernel timer tick on idle cores.
clocksource=tsc	Select the preferred kernel clock source.
nosoftlockup	Disables logging of backtraces when a process executes on a CPU or longer than the softlockup threshold (default 120 seconds).
mce=ignore_ce	Disable features for corrected errors.
cpuidle.off=1	Disable the cpuidle sub-system.
skew_tick=1	Causes the kernel to program each CPU’s tick timer to fire at different times to avoid any possible lock contention.
processor.max_cstate=0	Disables going from C0 into any other C-state.
isolcpus=	Isolates the cores from the scheduler.
rcunocbs=	Restricts these cores from receiving any rcu call backs.
rcu_nocb_poll	Relieves each CPU from the responsibility awakening their RCU offload threads. Using the combination of rcunocbs and rcu_nocb_poll reduces the interference on your benchmark cpus.
nohz_full=	Restricts cores from receiving any timer ticks if only one
acpi_irq_nobalance	ACPI will not move active IRQs.

六、参考文档

• Power Management - Technology Overview
• Enhanced Power Management for Low-Latency Workloads
• Power Management - Dynamic Receive Side to Increase Sleep State Residency Solution Brief
• How To Set CPU Power Management States
• intel/CommsPowerManagement
• Using Processor Idle C-States with Linux on ThinkSystem Servers
• Using Processor Performance P-States with Linux on Intel-based ThinkSystem Servers
• Using Intel Speed Select on ThinkSystem Servers
• ACPI-Wiki