修了linux一个存在12年的隐藏bug:Intel CPU离线再上线后,频率变了

问题背景

在一个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：

更多详细内容可见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的值。

前面已经提到，without 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 0x1992600# echo 0 > /sys/devices/system/cpu/cpu95/online# echo 1 > /sys/devices/system/cpu/cpu95/online# rdmsr -p 95 0x199800# 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 0x1992600# echo 0 > /sys/devices/system/cpu/cpu191/online# echo 1 > /sys/devices/system/cpu/cpu191/online# rdmsr -p 191 0x199800# rdmsr -p 95 0x199800# 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 0x1992300# 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.cindex 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);