Linux调度器队列、任务组及CPU亲和性相关技术问询

给定前提条件 #

• 所有线程采用SCHED_OTHER调度策略
• 所有线程为非实时线程（sched_priority为0）
• 内核已启用CONFIG_FAIR_GROUP_SCHED配置
• 自动分组功能已启用
• 存在两个Linux会话，各对应一个进程组

场景1：无CPU亲和性，两组均为单线程进程 #

用户理解回顾 #

同一进程组内的线程会被归入同一任务组。CFS调度器会确保两个进程组在共享核心上获得大致相等的时间片。nice值仅影响同一任务组内的调度顺序，组内调度由nice值和线程离开核心的时长决定。

问题解答 #

问题1：Linux是否会为每个任务组维护一棵红黑树？本场景下是否会存在2棵？

是的，每个任务组（对应此处的进程组）都会维护独立的CFS红黑树。本场景下存在2个任务组，因此会有2棵红黑树，每棵树对应一个进程组内的单线程任务。CFS通过红黑树按虚拟运行时间排序，跟踪组内所有可运行任务。

问题2：由于nice值不影响跨任务组的调度顺序，是否存在独立队列来决定遍历哪个任务组的红黑树以获取下一个待调度线程？

存在。启用CONFIG_FAIR_GROUP_SCHED后，CFS会在顶层维护一个组调度实体红黑树，节点为各任务组的调度实体（而非单个线程）。调度器会先从该组级树中选择虚拟运行时间最小的任务组，再从该组内部的红黑树中挑选下一个待调度线程。nice值仅影响组内任务的虚拟运行时间计算，不会干预组级调度排序。

问题3：是否可设置类似进程组间nice值的参数，确保多数情况下一个进程组优先于另一个？

可以，通过cgroup的CPU子系统实现：

• 使用cpu.shares参数（默认值1024）控制组间CPU时间分配比例，例如将组A设为2048、组B设为1024，资源紧张时组A会获得约2/3的CPU时间；
• 也可通过cpu.cfs_quota_us和cpu.cfs_period_us限制或保障组的CPU时间配额，进一步强化组级调度偏向。

场景2：无CPU亲和性，两组均为多线程进程 #

问题4：若进程为多线程，Linux调度器是否会为每个进程额外维护一个优先级队列（在进程组内的进程队列之上）以确定特定进程所生成线程的调度顺序？还是将同一进程组内各进程生成的所有线程视为独立任务，加入任务组的优先级队列？ #

CFS采用任务组 → 进程 → 线程的三层嵌套调度结构，每个层级都有独立的调度实体和红黑树：

1. 任务组的红黑树节点是组内的进程调度实体；
2. 每个进程的红黑树节点是其下属的所有线程；
3. 线程是最终调度单元，其调度实体包含虚拟运行时间等核心调度信息。

调度时会按层级依次选择：先选任务组，再选组内进程，最后选进程内线程。并非将所有线程直接归入任务组的红黑树，而是通过嵌套结构保障各级资源分配比例的有效性。

场景3：多线程进程，且每个进程设置不重叠的CPU亲和性 #

问题5：在此情况下，为每个进程组创建的任务组仍有意义吗？现在仅同一进程内的线程竞争CPU，跨进程及跨进程组的线程不再竞争核心。CFS调度器会如何调整任务组？此时为进程组维护红黑树似乎并无意义。 #

任务组仍然有意义，但作用会被弱化：

• 即使跨组线程不在同一核心竞争，任务组的资源限制（如cpu.shares、cpu.cfs_quota_us）依然生效，比如某个进程组的总CPU使用量仍会被限制在配额内；
• 内核不会主动删除任务组的红黑树结构，因为任务组配置是全局的，需保留以应对后续配置变更或亲和性调整。但实际调度中，单个核心只会处理绑定到自身的任务对应的进程、线程层级红黑树，组级红黑树不会被遍历。

问题6：每个逻辑CPU是否拥有独立于调度器的专属队列？

是的，每个逻辑CPU都有独立的运行队列（runqueue），包含该CPU上可运行的实时任务队列、CFS嵌套任务队列（组、进程、线程调度实体结构）。调度器核心工作就是管理各CPU的runqueue，选择下一个待运行任务，这种设计能减少跨CPU调度开销，提升效率。

内容的提问来源于stack exchange，提问作者MultiThreader