Linux进程调度如何决定下一个运行的进程task_struct与sched_entity内部机制【免费下载链接】linuxLinux kernel source tree项目地址: https://gitcode.com/GitHub_Trending/li/linux在终端里敲下一条sleep 300按回车这个进程就不再出现在top的活跃列表里但杀进程时它依然活着。它没有消失只是切换了状态而内核每隔一个时间片都要重新回答同一个问题下一个 CPU 周期给谁这个问题的答案就存在两个结构体里记录进程全部信息的task_struct以及调度器真正拿来比较的sched_entity调度实体可理解为 task_struct 里那张专门给调度器看的评分卡。下面把这张评分卡的字段、排序规则和唤醒到重新上 CPU 的完整路径讲清楚。机制在代码中的位置三个文件看完全貌调度机制横跨三处代码状态与结构体定义在 include/linux/sched.hCFS 公平调度器的算法主体在 kernel/sched/fair.c用户可见的统计输出在 kernel/sched/debug.c。字段 / 常量作用源码位置task_struct.__state32 位位图标记进程当前处于运行还是哪一类睡眠include/linux/sched.h#L843TASK_RUNNING等状态位各状态对应的位掩码TASK_RUNNING为0x0可运行即无标志位include/linux/sched.h#L106-L127task_struct.prio/static_prio/normal_prio静态优先级、nice 换算的优先级、含动态调整后的最终优先级include/linux/sched.h#L884-L886task_struct.se普通进程fair 类的调度实体内嵌在 task_struct 中include/linux/sched.h#L889task_struct.rt/dl实时类SCHED_FIFO/RR与截止时间类SCHED_DEADLINE各自的调度实体include/linux/sched.h#L890-L891sched_entity.load由 nice 值换算出的进程权重权重越大分到的 CPU 时间越多include/linux/sched.h#L574sched_entity.run_node红黑树节点该进程在队列中的挂靠点include/linux/sched.h#L576sched_entity.vruntime虚拟运行时间排序与比较的核心include/linux/sched.h#L592sched_entity.sum_exec_runtime该进程累计的真实 CPU 时间纳秒不受 nice 影响include/linux/sched.h#L590sched_entity.avg负载平均值PELT指数加权滑动平均供负载均衡与 util clamp 使用include/linux/sched.h#L618sched_entity.slice/min_vruntime当前时间片长度队列中虚拟时间的最小值缓存include/linux/sched.h#L597, L578task_struct 中三种调度类实体并列存放每个进程同时带着这三张卡但同一时刻只有一张卡对当前调度类生效struct task_struct { /* ... */ struct sched_entity se; /* fair 类进程使用的调度实体 */ struct sched_rt_entity rt; /* SCHED_FIFO / SCHED_RR 实时进程 */ struct sched_dl_entity dl; /* SCHED_DEADLINE 截止时间进程 */ };se内部与调度决策直接相关的部分完整定义约 48 行此处只摘核心struct sched_entity { struct load_weight load; /* nice 值换算出的权重 */ struct rb_node run_node; /* 红黑树节点 */ u64 vruntime; /* 虚拟运行时间排序依据 */ u64 sum_exec_runtime; /* 真实累计执行时间 */ u64 vlag; /* 虚拟滞后的近似值EEVDF 使用 */ u64 slice; /* 当前时间片 */ struct sched_avg avg; /* 负载平均值 */ };推演一个进程从睡眠到再次上 CPU 的完整路径以最典型的事件流走一遍sleep 300被定时器唤醒之后CFS 如何把它重新放上 CPU。定时器到期调度器把task_struct.__state从TASK_INTERRUPTIBLE改回TASK_RUNNING进程重新可运行。进程经由enqueue_task_fair()挂回该 CPU 的 CFS 运行队列实体插入红黑树位置由vruntime与队列最小值min_vruntime的差决定。当前进程每运行一个时间片update_curr()把真实经过的时间除以权重load后累加进vruntime——权重小的进程虚拟时间涨得快下次轮到它就更晚。需要换人时pick_next_entity()取出虚拟期限deadline由 vruntime 加时间片推算最早的进程。调度器执行上下文切换保存旧进程的寄存器与pcpu上下文恢复新进程旧进程若被抢占重新排队回到第 2 步循环。这里值得单独说明vruntime的虚拟二字它不是墙上时钟时间而是真实执行时间经过权重缩放后的量。nice 值越高的进程权重越小、vruntime涨得越快于是它连续获得 CPU 的机会越少——公平性正是靠这一把变速的尺子实现的而不是靠给不同进程分配不同长度的真实时间片。验证一条命令读出评分卡不需要编译内核/proc/pid/sched就是kernel/sched/debug.c直接导出的实体快照pid$(pidof sleep) grep -E se\.(vruntime|sum_exec_runtime|slice)|nr_involuntary|prio /proc/$pid/sched典型输出及字段含义输出字段对应实体字段含义se.vruntimese.vruntime虚拟运行时间秒.纳秒拆分显示队列排序依据se.sum_exec_runtimese.sum_exec_runtime真实累计 CPU 时间与 nice 无关se.slicese.slice内核当前分配给该进程的时间片长度nr_involuntary_switchesp-nivcsw被内核强制切走的次数非主动让出priop-normal_prio最终生效的优先级含动态调整对比同一进程的两个数就能看懂权重换算sum_exec_runtime是它实际消耗了多少 CPUvruntime是被除以权重之后的账本——对高 nice 进程vruntime会明显大于sum_exec_runtime。当前内核的调度参数与旧资料里的说法不同速查如下参数查看方式说明base_slice_nscat /sys/kernel/debug/sched/base_slice_ns需挂载 debugfs时间片基准由 CPU 频率推导而非固定 4 ms各类调度特性开关sysctl -a \| grep kernel.sched_如sched_autogroup_enabled等EEVDF 时代sched_latency_ns、sched_min_granularity_ns等旧参数已移除每 CPU 队列统计cat /proc/sched_debug各 CPU 上min_vruntime、nr_running等队列状态全局调度事件计数cat /proc/schedstat按 CPU 汇总的切换次数与运行时间误区与边界vruntime不是真实时间两者不能相减比较。它是权重缩放后的虚拟量想统计一个进程真正消耗了多少 CPU看sum_exec_runtime或用pidstat -t -p拿vruntime当秒数用会得到错误结论。红黑树排序的键已经不是vruntime本身。自 EEVDF 取代 CFS 以来设计见 Documentation/scheduler/sched-eevdf.rst选择依据是deadlinevruntime 加上时间片推算出的虚拟截止时间min_vruntime也改为缓存最小 deadline 的近似值。旧文档里挑 vruntime 最小的进程这一句在当下内核只算近似正确。sched_entity只对 fair 类进程有效。用SCHED_FIFO提权的实时线程走rt实体、纯轮转链表dl类进程走截止时间队列它们运行时会直接抢占 CFS 队列/proc/pid/sched里那几个se.*字段对实时进程基本无意义。判断方法ps -o pid,cls,ni -p pid看调度类是否为FIFO/RR/DL。延伸task_struct是进程的全部档案sched_entity只是其中交给调度器的那张评分卡看懂权重如何换算vruntime、deadline如何参与选择就能解释绝大多数我的进程为什么拿不到 CPU的现象。继续深入可先读官方调度器文档再对照 kernel/sched/fair.c 中enqueue_task_fair、update_curr、pick_next_entity三个函数的实现。Documentation/scheduler/sched-design-CFS.rstCFS 原始设计文档Documentation/scheduler/sched-eevdf.rstEEVDF 调度算法设计kernel/sched/debug.c/proc/pid/sched等接口的实现【免费下载链接】linuxLinux kernel source tree项目地址: https://gitcode.com/GitHub_Trending/li/linux创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Linux进程调度如何决定下一个运行的进程task_struct与sched_entity内部机制【免费下载链接】linuxLinux kernel source tree项目地址: https://gitcode.com/GitHub_Trending/li/linux在终端里敲下一条sleep 300按回车这个进程就不再出现在top的活跃列表里但杀进程时它依然活着。它没有消失只是切换了状态而内核每隔一个时间片都要重新回答同一个问题下一个 CPU 周期给谁这个问题的答案就存在两个结构体里记录进程全部信息的task_struct以及调度器真正拿来比较的sched_entity调度实体可理解为 task_struct 里那张专门给调度器看的评分卡。下面把这张评分卡的字段、排序规则和唤醒到重新上 CPU 的完整路径讲清楚。机制在代码中的位置三个文件看完全貌调度机制横跨三处代码状态与结构体定义在 include/linux/sched.hCFS 公平调度器的算法主体在 kernel/sched/fair.c用户可见的统计输出在 kernel/sched/debug.c。字段 / 常量作用源码位置task_struct.__state32 位位图标记进程当前处于运行还是哪一类睡眠include/linux/sched.h#L843TASK_RUNNING等状态位各状态对应的位掩码TASK_RUNNING为0x0可运行即无标志位include/linux/sched.h#L106-L127task_struct.prio/static_prio/normal_prio静态优先级、nice 换算的优先级、含动态调整后的最终优先级include/linux/sched.h#L884-L886task_struct.se普通进程fair 类的调度实体内嵌在 task_struct 中include/linux/sched.h#L889task_struct.rt/dl实时类SCHED_FIFO/RR与截止时间类SCHED_DEADLINE各自的调度实体include/linux/sched.h#L890-L891sched_entity.load由 nice 值换算出的进程权重权重越大分到的 CPU 时间越多include/linux/sched.h#L574sched_entity.run_node红黑树节点该进程在队列中的挂靠点include/linux/sched.h#L576sched_entity.vruntime虚拟运行时间排序与比较的核心include/linux/sched.h#L592sched_entity.sum_exec_runtime该进程累计的真实 CPU 时间纳秒不受 nice 影响include/linux/sched.h#L590sched_entity.avg负载平均值PELT指数加权滑动平均供负载均衡与 util clamp 使用include/linux/sched.h#L618sched_entity.slice/min_vruntime当前时间片长度队列中虚拟时间的最小值缓存include/linux/sched.h#L597, L578task_struct 中三种调度类实体并列存放每个进程同时带着这三张卡但同一时刻只有一张卡对当前调度类生效struct task_struct { /* ... */ struct sched_entity se; /* fair 类进程使用的调度实体 */ struct sched_rt_entity rt; /* SCHED_FIFO / SCHED_RR 实时进程 */ struct sched_dl_entity dl; /* SCHED_DEADLINE 截止时间进程 */ };se内部与调度决策直接相关的部分完整定义约 48 行此处只摘核心struct sched_entity { struct load_weight load; /* nice 值换算出的权重 */ struct rb_node run_node; /* 红黑树节点 */ u64 vruntime; /* 虚拟运行时间排序依据 */ u64 sum_exec_runtime; /* 真实累计执行时间 */ u64 vlag; /* 虚拟滞后的近似值EEVDF 使用 */ u64 slice; /* 当前时间片 */ struct sched_avg avg; /* 负载平均值 */ };推演一个进程从睡眠到再次上 CPU 的完整路径以最典型的事件流走一遍sleep 300被定时器唤醒之后CFS 如何把它重新放上 CPU。定时器到期调度器把task_struct.__state从TASK_INTERRUPTIBLE改回TASK_RUNNING进程重新可运行。进程经由enqueue_task_fair()挂回该 CPU 的 CFS 运行队列实体插入红黑树位置由vruntime与队列最小值min_vruntime的差决定。当前进程每运行一个时间片update_curr()把真实经过的时间除以权重load后累加进vruntime——权重小的进程虚拟时间涨得快下次轮到它就更晚。需要换人时pick_next_entity()取出虚拟期限deadline由 vruntime 加时间片推算最早的进程。调度器执行上下文切换保存旧进程的寄存器与pcpu上下文恢复新进程旧进程若被抢占重新排队回到第 2 步循环。这里值得单独说明vruntime的虚拟二字它不是墙上时钟时间而是真实执行时间经过权重缩放后的量。nice 值越高的进程权重越小、vruntime涨得越快于是它连续获得 CPU 的机会越少——公平性正是靠这一把变速的尺子实现的而不是靠给不同进程分配不同长度的真实时间片。验证一条命令读出评分卡不需要编译内核/proc/pid/sched就是kernel/sched/debug.c直接导出的实体快照pid$(pidof sleep) grep -E se\.(vruntime|sum_exec_runtime|slice)|nr_involuntary|prio /proc/$pid/sched典型输出及字段含义输出字段对应实体字段含义se.vruntimese.vruntime虚拟运行时间秒.纳秒拆分显示队列排序依据se.sum_exec_runtimese.sum_exec_runtime真实累计 CPU 时间与 nice 无关se.slicese.slice内核当前分配给该进程的时间片长度nr_involuntary_switchesp-nivcsw被内核强制切走的次数非主动让出priop-normal_prio最终生效的优先级含动态调整对比同一进程的两个数就能看懂权重换算sum_exec_runtime是它实际消耗了多少 CPUvruntime是被除以权重之后的账本——对高 nice 进程vruntime会明显大于sum_exec_runtime。当前内核的调度参数与旧资料里的说法不同速查如下参数查看方式说明base_slice_nscat /sys/kernel/debug/sched/base_slice_ns需挂载 debugfs时间片基准由 CPU 频率推导而非固定 4 ms各类调度特性开关sysctl -a \| grep kernel.sched_如sched_autogroup_enabled等EEVDF 时代sched_latency_ns、sched_min_granularity_ns等旧参数已移除每 CPU 队列统计cat /proc/sched_debug各 CPU 上min_vruntime、nr_running等队列状态全局调度事件计数cat /proc/schedstat按 CPU 汇总的切换次数与运行时间误区与边界vruntime不是真实时间两者不能相减比较。它是权重缩放后的虚拟量想统计一个进程真正消耗了多少 CPU看sum_exec_runtime或用pidstat -t -p拿vruntime当秒数用会得到错误结论。红黑树排序的键已经不是vruntime本身。自 EEVDF 取代 CFS 以来设计见 Documentation/scheduler/sched-eevdf.rst选择依据是deadlinevruntime 加上时间片推算出的虚拟截止时间min_vruntime也改为缓存最小 deadline 的近似值。旧文档里挑 vruntime 最小的进程这一句在当下内核只算近似正确。sched_entity只对 fair 类进程有效。用SCHED_FIFO提权的实时线程走rt实体、纯轮转链表dl类进程走截止时间队列它们运行时会直接抢占 CFS 队列/proc/pid/sched里那几个se.*字段对实时进程基本无意义。判断方法ps -o pid,cls,ni -p pid看调度类是否为FIFO/RR/DL。延伸task_struct是进程的全部档案sched_entity只是其中交给调度器的那张评分卡看懂权重如何换算vruntime、deadline如何参与选择就能解释绝大多数我的进程为什么拿不到 CPU的现象。继续深入可先读官方调度器文档再对照 kernel/sched/fair.c 中enqueue_task_fair、update_curr、pick_next_entity三个函数的实现。Documentation/scheduler/sched-design-CFS.rstCFS 原始设计文档Documentation/scheduler/sched-eevdf.rstEEVDF 调度算法设计kernel/sched/debug.c/proc/pid/sched等接口的实现【免费下载链接】linuxLinux kernel source tree项目地址: https://gitcode.com/GitHub_Trending/li/linux创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
