一、背景在之前的博客 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_rqcpuset_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_rqdo_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的地址上3.3 migrate_disabled的任务会影响cpu offline要注意任务如果以migrate_disabled的状态一直没有得到调度那么该cpu是不能offline的用于检查rq上是否有该类型任务的函数是rq_has_pinned_tasks对应于migrate_disable里下图的nr_pinned的设置有关为什么会导致cpu无法offline在之前的博客 里的 3.1 一节里有介绍。3.4 migrate_enable的逻辑migrate_enable里会把cpus_mask重新通过__set_cpus_allowed_ptr设置到cpus_ptr上调用链migrate_enable__set_cpus_allowed_ptr(p, ac);__set_cpus_allowed_ptr_locked(p, ctx, rq, rf);__do_set_cpus_allowed(p, ctx);p-sched_class-set_cpus_allowed(p, ctx);.set_cpus_allowed set_cpus_allowed_common,p-cpus_ptr ctx-new_mask;