当前位置：首页 > news >正文

migrate_disable_switch及cpus_ptr、user_cpus_ptr的相关细节

news 2026/6/5 22:09:39

一、背景

在之前的博客 cpu offline/online时线程的绑核属性设置的相关细节里，我们做了有关cpu绑核属性的一些相关实验，针对的是cpu offline/online的切换的场景，其实这个场景下进行分析比较好能帮助我们理解task_struct里的有关绑核属性的如cpus_ptr、user_cpus_ptr、cpus_mask这些数值的具体含义，我们在第二章里针对之前博客里的实验结果做进一步细节阐述，在第三章里，我们针对另一个相关函数migrate_disable_switch进行分析。

二、cpus_ptr、user_cpus_ptr、cpus_mask的相关细节

我们先通过如下命令，剔除掉堆栈调用链的打印，只关注cpus_ptr、user_cpus_ptr、cpus_mask这几个变量的数值以及调用set_cpus_allowed_common时的入参ctx的ctx->flags的数值：

2.1 user_cpus_ptr记录着用户设置的绑核属性

如上图可以看到user_cpus_ptr指向的数值在cpu从online变offline，再从offline变online，整个期间都保持不变，所以，它是记录着实际用户设置的绑核属性，但是要注意：

1）用户设置的绑核属性会因为cpu的offline的情况而不能真正应用到任务的绑核属性里去

2）一旦cpu的offline事件导致任务的没有可选用的核的话会触发select_fallback_rq的例程，user_cpus_ptr会被设为NULL（有关这个实验及原理见下面 2.2 一节）

2.2 user_cpus_ptr在cpu offline后没有可选核时的变化及调用栈

复现还是比较方便的，就是如下图：

先设置任务的绑核属性到cpu1上，然后把cpu1下线，查看内核日志。

如下图红色框出的部分可以看到，user_cpus_ptr在cpu1下线的时候，user_cpus_ptr由有值的情况变成NULL：

另外可以看到，before after为一组，进行了三组，也就是在cpu1下线时，调用了三次set_cpus_allowed_common函数。我们一次次地来进行分析相关的调用栈。

第一次：

如上图，是在调用__balance_push_cpu_stop时，如下图，调用了select_fallback_rq函数：

而__balance_push_cpu_stop则是之前的博客 balance_callbacks及cpu offline的相关细节里介绍balance_push里的一个关键步骤：

回到select_fallback_rq的函数：

看对应源代码：

select_fallback_rq

cpuset_cpus_allowed_fallback—————if (cpuset_cpus_allowed_fallback(p)) {

可以和堆栈对上的：

这次设置是如下图，在cpuset_cpus_allowed_fallback里调用do_set_cpus_allowed标记上了SCA_USER的flags，然后要设置的user_mask为NULL：

这样，最终调用到set_cpus_allowed_common的时候，如下图，就将user_cpus_ptr交换成了NULL：

第一次执行完之后，如下图，cpus_mask是空的，这肯定是不行的：

来看第二次：

对应调用链：

select_fallback_rq

do_set_cpus_allowed(p, task_cpu_possible_mask(p));

__do_set_cpus_allowed(p, &ac);

对应代码里select_fallback_rq的部分：

在执行了上图里的红色框出的逻辑之后，cpus_mask变成了：cpu_possible_mask，这是包含还正在下线过程中的cpu的：

第三次的调用如下图可以看到就是触发了work去做cpu offline时的设置剔除offline cpu的绑核属性的逻辑：

第三次完成之后，就是cpu_possible_mask剔除了offline的cpu的状态：

2.3 总结一下user_cpus_ptr在cpu offline后没有可选核的调用

其实上面的 2.2 里分析的三次调用的前两次就是下图里的这个for循环，依次看case cpuset，然偶是case possible，也就是先看cgroup的cpuset的范围是否可以选出来可以跑的cpu，然后再去用possible的mask，注意，case cpuset的里头的逻辑的break，只是跳出了switch的case，还是要重新回到for循环去检查is_cpu_allowed是否p任务可以在dest_cpu上跑：

先从cgroup的cpuset作为mask的逻辑如下图，下图里的is_in_v2_mode就是检查是否是cgroup v2：

三、migrate_disable_switch的相关细节

在set_cpus_allowed_common的逻辑里有如下红色框出的逻辑：

这部分逻辑是和另外一个会在__schedule()里调用的migrate_disable_switch的逻辑相关的：

在__schedule()时，如果发现需要切换任务（也就是prev != next），那么就需要检查prev的任务是否处于migrate_disabled的状态，在rt-linux里进入普通spinlock后，如果被实时任务抢占，就会变成migrate_disabled的状态，当然migrate_disabled还有别的很多情况，migrate_disabled的状态是一个还算比较常见的状态。在检查到任务是migrate_disabled的状态的话，就要设置cpus_mask到当前任务所在的rq对应的cpus_mask上，其实也就是这一个cpu的mask。

3.1 rq的cpumask

已经有了task_struct里的cpus_mask，为什么还需要有rq的这个cpumask，这是因为migrate_disabled的状态是一个临时状态，而migrate_enable之后，需要对cpumask进行恢复，那么cpumask就是记录着之前的旧的cpu的mask状态。

这也反映出一点，就是task_struct的cpus_mask并不是真正的任务的即刻的绑核属性状态，而任务当前实际的绑核属性状态是由cpus_ptr所指向，也是为什么migrate_disable_switch的下图里的set_cpus_allowed_common函数里的红色框出的部分，在设置完p->cpus_ptr后就可以直接返回了：

3.2 migrate_disable_switch下判断cpus_ptr是否指向cpus_mask

正是因为上图里的红色框出的这个设置，在migrate_disable_switch的下图逻辑，在判断出如果cpus_ptr已经不等于&p->cpus_mask的话，就可以直接返回了，因为已经设置过了，如果不是该migrate_disable_switch导致的特殊设置cpus_ptr成rq的cpumask，那么cpus_ptr一直会指向到cpus_mask的地址上：