问题背景
在一个intel的机器上做测试发现一个问题，该机器的相关配置如下：开启smt、使用intel_cpufreq驱动、不开启hwp、intel pstate驱动为passive模式、开启all-core turbo全核睿频、使用performance governor。
如果把一个core对应的两个smt的cpu都offline一下然后重新oneline，这个core上的两个cpu的频率都维持在基频，而不是all-core turbo的频率。而如果只把这个core的其中一个smt cpu offline掉然后重新online，那么这个cpu还可以恢复all-core turbo的频率。这是因为什么呢？需要详细排查一下。
相关知识
HWP(hardware-managed P-states)：硬件支持的p-state，intel pstae允许让硬件自己管理pstate状态
intel_pstate的active模式和passive模式：active模式就是用intel_pstate内建的算法或者使用HWP硬件自己调节pstate。passive模式就还是使用那些通用的governor。
一些msr：
| MSR名字 | 作用 |
|---|---|
| MSR_IA32_PERF_STATUS | 反应当前cpu所处的pstate状态 |
| MSR_IA32_PERF_CTL | 可以通过写入这个msr来向pstate驱动请求修改pstate状态 |
| MSR_IA32_MPERF | 以cpu标称基准频率递增的计数器，通常与MSR_IA32_APERF一起配合计算当前的实际cpu频率 |
| MSR_IA32_APERF | 以cpu当前运行的实际频率递增的计数器，通常与MSR_IA32_MPERF一起配合计算当前的实际cpu频率 |
更多详细内容可见Linux源码中:Documentation/admin-guide/pm/intel_pstate.rst
定位及解决
排查过程
我们直接看一下echo 0 > /sys/devices/system/cpu/cpuXXX/online之后，调用的intel_pstate的offline(也就是intel_cpufreq_cpu_offline)做了什么。
static int intel_cpufreq_cpu_offline(struct cpufreq_policy *policy)
{
struct cpudata *cpu = all_cpu_data[policy->cpu];
......
if (hwp_active)
intel_pstate_hwp_offline(cpu);
else
intel_pstate_set_min_pstate(cpu);
intel_pstate_exit_perf_limits(policy);
return 0;
}
可以看到，如果没有开启hwp的话，则去调用intel_pstate_set_min_pstate，那么这个函数是干什么的？
static void intel_pstate_set_min_pstate(struct cpudata *cpu)
{
intel_pstate_set_pstate(cpu, cpu->pstate.min_pstate);
}
static void intel_pstate_set_pstate(struct cpudata *cpu, int pstate)
{
trace_cpu_frequency(pstate * cpu->pstate.scaling, cpu->cpu);
cpu->pstate.current_pstate = pstate;
wrmsrq_on_cpu(cpu->cpu, MSR_IA32_PERF_CTL,
pstate_funcs.get_val(cpu, pstate));
}
显而易见，就是把通过wrmsrq_on_cpu设置MSR_IA32_PERF_CTL msr为最小的pstate的值。
前面已经提到，withou HWP+performance的模式下，intel pstate驱动总是会选择允许使用的最大的p-state。而这里把MSR_IA32_PERF_CTL设置成了最小的pstate值，再联系背景中，只有把一个core中的两个smt cpu全都offline然后online之后才会复现这个问题，合理怀疑是不是offline cpu之后设置了MSR_IA32_PERF_CTL为最小pstate但是online之后没有恢复？
做个实验看一下：
//95和191号cpu是一个core中的两个smt
# rdmsr -p 95 0x199
2600
# echo 0 > /sys/devices/system/cpu/cpu95/online
# echo 1 > /sys/devices/system/cpu/cpu95/online
# rdmsr -p 95 0x199
800
# cpupower monitor
| Nehalem || Mperf
PKG|CORE| CPU| C3 | C6 | PC3 | PC6 || C0 | Cx | Freq
.......
1| 47| 95| 0.00| 0.00| 0.00| 0.00|| 1.35| 98.65| 3098
1| 47| 191| 0.00| 0.00| 0.00| 0.00|| 1.20| 98.80| 3098
# rdmsr -p 191 0x199
2600
# echo 0 > /sys/devices/system/cpu/cpu191/online
# echo 1 > /sys/devices/system/cpu/cpu191/online
# rdmsr -p 191 0x199
800
# rdmsr -p 95 0x199
800
# cpupower monitor
| Nehalem || Mperf
PKG|CORE| CPU| C3 | C6 | PC3 | PC6 || C0 | Cx | Freq
.......
1| 47| 95| 0.00| 0.00| 0.00| 0.00|| 2.60| 97.40| 799
1| 47| 191| 0.00| 0.00| 0.00| 0.00|| 3.95| 96.05| 799
这里可以看到，如果我先offline 95号cpu然后online，这个cpu的MSR_IA32_PERF_CTL确实从2600变成了800，而cpupower monitor的结果中，95号cpu的频率依旧是3100Khz。然后我又把同core的另一个191号cpu执行了一遍offline和online，191号cpu和95号cpu的MSR_IA32_PERF_CTL都变成了800，cpupower monitor中的频率变成了800Khz。
所以，这里差不多就可以实锤是intel_cpufreq_cpu_offline中设置了MSR_IA32_PERF_CTL为最小pstate值但是online没有恢复。
那么我们手动设置95或191号cpu中的其中任何一个cpu的MSR_IA32_PERF_CTL为2600是不是就好了？试一下
# wrmsr -p 95 0x199 0x2300
# rdmsr -p 95 0x199
2300
# cpupower monitor
| Nehalem || Mperf
PKG|CORE| CPU| C3 | C6 | PC3 | PC6 || C0 | Cx | Freq
......
1| 47| 95| 0.00| 0.00| 0.00| 0.00|| 1.35| 98.65| 3098
1| 47| 191| 0.00| 0.00| 0.00| 0.00|| 1.14| 98.86| 3098
确实恢复了。
到这里，我们就发现了一个bug及其os层面上的解决方法。但是，还有一些问题我们没有查明原因，还需要深挖：为什么intel_cpufreq_cpu_offline中要把MSR_IA32_PERF_CTL设置成最小pstate？online过程中为什么没有恢复？怎么在代码层面解决这个问题？
为什么offline cpu要设置MSR_IA32_PERF_CTL
其实这个问题在intel_cpufreq_cpu_offline函数中的一段注释中可以找到原因
/*
* If the CPU is an SMT thread and it goes offline with the performance
* settings different from the minimum, it will prevent its sibling
* from getting to lower performance levels, so force the minimum
* performance on CPU offline to prevent that from happening.
*/
这一段就很明显了，如果当前cpu是一个某个core上的一个smt的话，如果在offline的时候不把他设置成最小的pstate值，那么他会阻止这个core上的其他的smt cpu进入更低的pstate级别。
我们简单画个图理解一下：
根本原因在于：intel_pstate的频率调节是per-core的。也就是，一个core上的两个smt cpu具有相同的频率，这个频率是intel_pstate驱动根据两个cpu的MSR_IA32_PERF_CTL综合计算来的。在offline一个cpu的时候，如果不把该cpu的MSR_IA32_PERF_CTL显式设置成最小的pstate值，那么他就有可能是任何值，有可能就是最大值。那么该core中的另一个cpu尝试通过cpupower frequency-set之类的命令去降低一下频率的话，是无法实现的，因为offline的cpu中的MSR_IA32_PERF_CTL可能是最大值，intel_pstate驱动可能一直根据这个值来设置这个core上的cpu频率。这样的话，一个cpu虽然offline了，但是他曾经设置的MSR_IA32_PERF_CTL还会一直影响在线的cpu。
为什么onelin过程没有恢复MSR_IA32_PERF_CTL
上面我们知道了为什么offline cpu的过程中会把MSR_IA32_PERF_CTL设置成最小pstate，接下来我们研究一下cpu online的过程，看一下为什么online过程中为什么没有恢复MSR_IA32_PERF_CTL？
看一下cpu online的过程中cpufreq相关的处理，会调用到cpufreq_online函数：查看当前这个cpu是否已经存在一个policy了，如果存在的话，则直接去调用cpufreq_add_policy_cpu就好
static int cpufreq_online(unsigned int cpu)
{
struct cpufreq_policy *policy;
bool new_policy;
int ret;
pr_debug("%s: bringing CPU%u online\n", __func__, cpu);
/* Check if this CPU already has a policy to manage it */
//offline后又重新online的cpu，policy是已经存在的
policy = per_cpu(cpufreq_cpu_data, cpu);
if (policy) {
WARN_ON(!cpumask_test_cpu(cpu, policy->related_cpus));
if (!policy_is_inactive(policy))
return cpufreq_add_policy_cpu(policy, cpu);
......
cpufreq_add_policy_cpu中判断如果对应的pstate驱动有target函数指针的话，则调用cpufreq_start_governor函数
static int cpufreq_add_policy_cpu(struct cpufreq_policy *policy, unsigned int cpu)
{
......
if (has_target()) {
ret = cpufreq_start_governor(policy);
if (ret)
pr_err("%s: Failed to start governor\n", __func__);
}
......
cpufreq_start_governor函数中，判断如果governor有limits函数指针的话，则去调用驱动对应的limit函数，对于我们的performance模式的话，则是去调用cpufreq_gov_performance_limits函数
int cpufreq_start_governor(struct cpufreq_policy *policy)
{
......
if (policy->governor->limits)
policy->governor->limits(policy);
......
cpufreq_gov_performance_limits实际上就是调用__cpufreq_driver_target函数
static void cpufreq_gov_performance_limits(struct cpufreq_policy *policy)
{
pr_debug("setting to %u kHz\n", policy->max);
__cpufreq_driver_target(policy, policy->max, CPUFREQ_RELATION_H);
}
__cpufreq_driver_target函数中可以看到，如果target_freq == policy->cur且后面一并判断条件成立的话，则直接return，就不再去尝试调用intel_pstate对应的target函数了，也就是intel_cpufreq_target函数，而intel_cpufreq_target函数中的intel_cpufreq_update_pstate函数正是去写msr去更新MSR_IA32_PERF_CTL的。
int __cpufreq_driver_target(struct cpufreq_policy *policy,
unsigned int target_freq,
unsigned int relation)
{
......
if (target_freq == policy->cur &&
!(cpufreq_driver->flags & CPUFREQ_NEED_UPDATE_LIMITS))
return 0;
if (cpufreq_driver->target) {
if (!policy->efficiencies_available)
relation &= ~CPUFREQ_RELATION_E;
return cpufreq_driver->target(policy, target_freq, relation);
}
......
static int intel_cpufreq_target(struct cpufreq_policy *policy,
unsigned int target_freq,
unsigned int relation)
{
struct cpudata *cpu = all_cpu_data[policy->cpu];
struct cpufreq_freqs freqs;
int target_pstate;
freqs.old = policy->cur;
freqs.new = target_freq;
cpufreq_freq_transition_begin(policy, &freqs);
target_pstate = intel_pstate_freq_to_hwp_rel(cpu, freqs.new, relation);
target_pstate = intel_cpufreq_update_pstate(policy, target_pstate, false);
freqs.new = target_pstate * cpu->pstate.scaling;
cpufreq_freq_transition_end(policy, &freqs, false);
return 0;
}
问题根因
综上，我们可以用一张图来展示这个bug产生的根因：
一句话总结：offline cpu的时候只设置了MSR_IA32_PERF_CTL为最小pstate，但是没有同步更新该cpu对应的policy。online该cpu的时候，就因为目标target_freq与之前没有更新的policy->cur相同而直接return，不再去更新该cpu的MSR_IA32_PERF_CTL，故导致该cpu的pstate一直处于最小pstate状态。
怎么在驱动代码层面解决这个问题
只需要在offline cpu设置MSR_IA32_PERF_CTL为最小pstate的时候同步更新一下policy就好了
diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
index 1292da53e5fc..11db1c887c80 100644
--- a/drivers/cpufreq/intel_pstate.c
+++ b/drivers/cpufreq/intel_pstate.c
@@ -2984,10 +2984,12 @@ static int intel_cpufreq_cpu_offline(struct cpufreq_policy *policy)
* from getting to lower performance levels, so force the minimum
* performance on CPU offline to prevent that from happening.
*/
- if (hwp_active)
+ if (hwp_active) {
intel_pstate_hwp_offline(cpu);
- else
+ } else {
intel_pstate_set_min_pstate(cpu);
+ policy->cur = cpu->pstate.min_freq;
+ }
intel_pstate_exit_perf_limits(policy);
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 857879363@qq.com