Linux 0.11 进程状态变迁的日志追踪与性能分析实践

1. 为什么我们要追踪进程的一生如果你刚开始学习操作系统或者对Linux内核充满好奇但又觉得那些抽象的概念——比如“进程状态”、“调度”、“上下文切换”——听起来像天书那么我强烈建议你试试这个实验。我自己当年就是这么过来的啃着厚厚的教材脑子里塞满了“就绪”、“运行”、“阻塞”这些名词但总觉得隔着一层纱看不见摸不着。直到我亲手在Linux 0.11的内核代码里插入了几个打印日志的语句然后看着一个进程从诞生到消亡的完整轨迹被清晰地记录下来那种“原来如此”的顿悟感至今难忘。这个实验的核心就是让内核自己“开口说话”。我们不再被动地接受书本上的状态转换图而是主动地、动态地去观察一个真实的进程在内核里究竟经历了什么。想象一下你就像一个给手术室安装监控摄像头的工程师能实时看到病人进程从进入手术室创建、等待手术就绪、进行手术运行、麻醉睡眠阻塞到离开手术室退出的全过程。每一个关键动作都被时间戳精准记录。它能帮你做什么首先它能将《操作系统原理》课本上那张经典的“进程三态图”或“五态图”彻底具象化。你会亲眼看到进程是如何通过fork()系统调用“出生”被调度器选中后“开跑”因为等待I/O而“睡着”被唤醒后又“跃跃欲试”最后完成任务后“安息”。其次通过分析这些日志你可以定量地分析操作系统的行为比如计算每个进程的周转时间、CPU利用率甚至通过调整时间片参数直观地看到调度策略的改变如何影响整个系统的“吞吐率”——也就是单位时间内能完成多少工作。这个实验非常适合正在学习操作系统课程的学生、对内核机制感兴趣的开发者或者任何想通过动手实践来深化理论理解的朋友。它不需要你事先成为内核专家只需要你有一份Linux 0.11的源码、一个能运行它的模拟环境比如Bochs以及一颗愿意折腾的心。接下来我就带你一步步搭建这个“监控系统”并一起分析我们收集到的宝贵数据。2. 搭建实验环境与理解追踪框架工欲善其事必先利其器。在开始修改内核之前我们得先把实验环境搭好。这个环境的核心是Linux 0.11内核和Bochs模拟器。Linux 0.11是一个非常经典且简洁的早期版本代码量小结构清晰是学习内核的绝佳材料。Bochs则是一个开源的x86模拟器它能在你的现代操作系统如Linux或Windows上完美模拟出一个老旧的PC环境来运行这个内核。我个人的环境是在Ubuntu下搭建的过程不算复杂。你需要先获取Linux 0.11的源代码和编译工具链。网上有很多现成的实验包比如哈工大操作系统课程配套的“oslab”包里面已经把内核、模拟器、编译工具都打包好了解压后按照说明运行几个脚本就能完成编译和安装非常方便。这里我就不再赘述具体的安装命令了因为不同的实验包步骤略有差异但核心都是1. 准备好源码和交叉编译器2. 编译生成内核镜像3. 配置Bochs使用这个镜像启动。环境准备好后我们来理解一下整个追踪框架的设计思路。我们的目标是在内核的关键位置插入“探针”每当进程状态发生变化时就向一个日志文件里写一行记录。记录的内容很简单进程ID (PID)、状态代码、时间戳。状态代码我们可以自己定义比如用N表示新建NewJ表示进入就绪队列Jion ready queueR表示开始运行RunningW表示进入等待/睡眠WaitE表示退出Exit。那么内核中哪些地方是“关键位置”呢这需要我们仔细阅读源码。进程的创建发生在fork.c的copy_process函数里进程被调度器选中开始运行发生在sched.c的schedule函数中具体是在调用switch_to进行上下文切换之前进程主动放弃CPU进入睡眠可能发生在sys_pause、sleep_on、interruptible_sleep_on这些函数里进程被唤醒则发生在wake_up函数里进程退出发生在exit.c的do_exit函数里。我们的任务就是找到这些函数中修改current-state当前进程状态的语句在它们旁边加上我们的日志记录函数。这里我们使用一个自定义的fprintk函数它是对内核printk的封装专门用于向一个提前打开的文件描述符比如我们为日志文件打开的写入格式化字符串。理解了这套“在哪里埋点、记录什么”的逻辑后面的代码修改就变成了按图索骥的精细活儿。3. 深入内核关键函数的日志埋点实战现在我们拿起“手术刀”开始在内核源码的特定位置插入日志记录代码。这个过程需要细心和耐心因为我们要确保日志记录在正确的时机发生并且不能破坏原有的逻辑。我会结合我踩过的一些坑详细讲解每一处修改。3.1 打开日志文件第一个陷阱一切追踪的开始是我们需要在内核中打开一个日志文件。按照直觉我们可能会在main.c的main函数最开始就这么做。但在Linux 0.11中main函数执行时内核的初始化还远未完成文件系统等可能还没就绪。更合适的时机是在init/main.c的init函数里。这个函数是内核初始化完成后启动第一个用户进程init的地方。// 在 init/main.c 的 init() 函数开头附近添加 void init(void) { // ... 其他初始化代码 ... (void) open(/var/process.log, O_CREAT|O_TRUNC|O_WRONLY, 0666); // ... 后续 fork 等操作 ... }这里有个大坑我踩过你不能把这行代码放在init函数之前。因为在这之前内核中只有唯一一个进程——任务0task[0]它主要负责内核初始化并不适合执行普通的文件操作。如果你让task[0]去打开文件Bochs模拟器可能会报一些奇怪的错误比如关于sync的错误。所以一定要确保打开文件的操作是由init进程也就是后来的任务1来执行的。3.2 记录进程的诞生与就绪进程的创建在kernel/fork.c的copy_process函数中。这个函数非常长它负责复制父进程的数据结构进程控制块PCB、内存空间等。我们需要关注两个点进程“诞生”当新的task_struct进程描述符被分配并初步填充后它的初始状态被设置为TASK_UNINTERRUPTIBLE不可中断睡眠。这是一个临时状态表示进程正在被创建尚未准备好运行。此时我们应该记录它的“新建”事件。进程“就绪”在copy_process函数的最后在返回之前会将进程状态设置为TASK_RUNNING可运行并把它加入到调度队列。此时进程已经创建完毕等待被调度执行。我们应该记录它的“就绪”事件。// 在 kernel/fork.c 的 copy_process 函数中 int copy_process(...) { struct task_struct *p; // ... 分配内存页复制数据等大量操作 ... p (struct task_struct *) get_free_page(); // ... 初始化 p 的各个字段 ... p-state TASK_UNINTERRUPTIBLE; // 状态设置为“不可中断睡眠” // 记录新建(N) fprintk(3, %ld\tN\t%ld\n, p-pid, jiffies); // ... 更多初始化设置时间片等 ... p-start_time jiffies; // ... 最后将进程状态改为可运行 p-state TASK_RUNNING; // 记录就绪(J) fprintk(3, %ld\tJ\t%ld\n, p-pid, jiffies); return last_pid; }这里的jiffies是内核的一个全局变量代表系统启动以来的“滴答”数我们可以把它当作粗糙的时间戳。3.3 调度器的核心记录运行与切换进程状态的切换大部分都发生在调度器schedule()函数在kernel/sched.c中里。这个函数是内核的心脏它决定下一个该谁运行。我们需要在几个地方埋点唤醒睡眠进程schedule开头有一个循环检查所有任务如果有任务设置了报警alarm或者收到了信号且处于可中断睡眠状态就将其状态改为TASK_RUNNING。这里需要记录一次从睡眠(W)到就绪(J)的转换。时间片用完当前进程让出CPU在schedule函数决定好下一个要运行的进程next之后在调用switch_to(next)进行实际切换之前。如果当前进程current的状态仍然是TASK_RUNNING说明它是时间片用完了而不是主动睡眠那么它应该从运行状态变为就绪状态。我们需要记录current的J事件。下一个进程开始运行紧接着上一步在切换之前记录下一个进程task[next]的R运行事件。// 在 kernel/sched.c 的 schedule 函数中 void schedule(void) { int i,next,c; struct task_struct ** p; // 第一部分检查并唤醒符合条件的睡眠进程 for(p LAST_TASK ; p FIRST_TASK ; --p) { if (*p) { // ... 检查 alarm 和 signal ... if (((*p)-signal ~(_BLOCKABLE (*p)-blocked)) (*p)-stateTASK_INTERRUPTIBLE) { (*p)-stateTASK_RUNNING; fprintk(3,%d\tJ\t%d\n,(*p)-pid,jiffies); // 睡眠-就绪 } } } // ... 调度算法主体选择 counter 值最大的就绪进程为 next ... // 第二部分记录状态切换 if(current-pid ! task[next] -pid) { // 如果当前进程还在运行状态时间片到则变为就绪 if(current-state TASK_RUNNING) { fprintk(3,%d\tJ\t%d\n,current-pid,jiffies); // 运行-就绪 } // 下一个进程开始运行 fprintk(3,%d\tR\t%d\n,task[next]-pid,jiffies); // 就绪-运行 } switch_to(next); }3.4 睡眠与唤醒记录等待的时刻进程主动进入睡眠通常是因为需要等待某个资源如I/O完成、信号量、子进程退出。Linux 0.11提供了几个主要的睡眠函数。sys_pause()这是一个系统调用使进程进入可中断睡眠直到收到一个信号。修改很简单在状态改变后记录。int sys_pause(void) { // 当前进程 运行 可中断睡眠 if(current-state ! TASK_INTERRUPTIBLE) fprintk(3,%d\tW\t%d\n,current-pid,jiffies); current-state TASK_INTERRUPTIBLE; schedule(); return 0; }sleep_on()和interruptible_sleep_on()这两个函数用于实现更复杂的等待队列比如等待一个缓冲区解锁。它们的逻辑稍微复杂一些涉及到将当前进程加入等待队列并设置前一个等待进程的状态。修改的原则是在current-state被设置为睡眠状态TASK_UNINTERRUPTIBLE或TASK_INTERRUPTIBLE之后立即记录W事件。同样在唤醒队列中其他进程将它们的state设为0即TASK_RUNNING时记录J事件。wake_up()函数也是类似的在唤醒队列头进程时记录J事件。3.5 进程的终结记录退出进程生命周期的终点在kernel/exit.c的do_exit()函数中。当进程执行完所有工作它会调用这个函数来释放资源并最终将状态设置为TASK_ZOMBIE僵尸状态等待父进程“收尸”。我们就在设置僵尸状态之后记录E事件。int do_exit(long code) { // ... 释放内存、关闭文件等清理工作 ... current-state TASK_ZOMBIE; fprintk(3, %ld\tE\t%ld\n, current-pid, jiffies); // 记录退出 schedule(); // 调用调度器永不返回 return (-1); }另外在sys_waitpid系统调用中如果父进程等待的子进程尚未结束父进程可能会将自己设置为可中断睡眠。这里也需要记录一个W事件。3.6 实现日志函数fprintk最后我们需要实现向文件写日志的函数。我们不能直接用用户态的fprintf因为内核里不能用。我们需要用内核提供的文件操作函数。通常的做法是修改kernel/printk.c添加一个fprintk函数。这个函数需要用到我们之前在init中打开的文件描述符假设是3。它内部调用sys_write系统调用向这个描述符写入格式化后的字符串。这里还有一个关键点文件描述符3是在进程1init进程的上下文中打开的。这意味着只有进程1及其子进程也就是所有用户进程才能继承并使用这个文件描述符。在内核的其他地方比如任务0的上下文调用fprintk可能会导致错误。所以在fprintk的实现里最好先判断一下当前进程的pid确保不是任务0。或者更常见的做法是我们只在进程1及其后代中调用我们添加的日志代码这本身也是合理的因为任务0是内核线程我们通常不追踪它。4. 运行测试与日志分析从数据到洞察完成所有代码修改后就是激动人心的编译和测试环节了。使用交叉编译器重新编译内核生成新的Image文件然后用Bochs加载运行。如果一切顺利系统应该能正常启动。接下来我们需要一个测试程序来“制造”一些进程活动。通常我们会写一个叫process.c的用户程序里面用fork()创建几个子进程每个子进程执行不同的计算和I/O混合任务比如用循环模拟CPU计算用sleep模拟I/O等待。将这个程序放在模拟系统的硬盘镜像里在内核启动后运行它。程序运行完毕后我们可以在/var/process.log中找到生成的日志文件。它的内容大概长这样2 N 100 2 J 100 3 N 105 3 J 105 2 R 110 2 W 150 3 R 155 2 J 200 ... 1 E 500每一行代表一个事件进程ID、状态码、时间戳jiffies。拿到这份原始日志我们就可以开始分析了。你可以写一个简单的Python脚本比如叫stat_log.py来解析它。脚本的任务包括统计每个进程的生命周期找到每个进程的N和E事件计算其存活时间周转时间。统计每个进程处于各状态的时间通过相邻事件的时间差可以计算出进程每次处于运行R、就绪J、等待W状态的时间长度然后求和。计算系统级的指标CPU利用率所有进程运行时间总和 / 总观察时间。吞吐率单位时间内例如每1000个jiffies完成E的进程数量。我第一次跑出日志并看到这些数字时感觉特别棒。书本上冷冰冰的“调度”、“并发”概念一下子变成了可以观察和测量的具体现象。你可以清晰地看到当某个进程进行I/O操作进入W状态时CPU立刻被调度给了另一个就绪进程这种重叠正是提高效率的关键。5. 进阶玩法调整时间片观察调度性能理解了基本的追踪后我们可以玩点更深入的修改调度参数观察系统性能的变化。Linux 0.11采用了一种简单的、基于优先级和时间片的轮转调度算法。每个进程有一个counter成员它就是时间片进程运行时counter递减减到0时就会被调度器换下。而counter的初始值等于进程的priority优先级。所以调整时间片最直接的方法就是修改所有进程的初始优先级。这个值定义在include/linux/sched.h头文件的INIT_TASK宏里这个宏定义了任务0init_task的初始值后续进程的优先级会从这里继承或设置。// 在 include/linux/sched.h 中 #define INIT_TASK \ { 0,15,15, // 这三个值分别对应 state、counter 和 priority ...我们把第三个值15改成其他数字比如5或10就相当于修改了默认的时间片长度。实验步骤将priority和counter初始值改为5重新编译内核并运行相同的process.c测试程序。收集日志用分析脚本计算吞吐率、平均周转时间等指标。再将值改为10重复测试。最后改为15默认值或更大如20再测试一次。你会观察到什么在我的多次实验中发现时间片并非越大越好也非越小越好存在一个“甜点”。时间片很小如5进程频繁因为时间片用完而被强制切换产生很多R-J和J-R事件。上下文切换的开销占比变大虽然响应看起来很快每个进程都能很快被轮到但系统用于真正干活的时间比例下降可能导致整体吞吐率降低。时间片很大如20CPU密集型进程会长时间霸占CPU如果此时有交互式或I/O密集的进程它们的响应性就会变差因为要等待很久。虽然切换开销小了但可能因为CPU资源分配不均衡导致某些进程等待时间过长整体吞吐率也可能达不到最优。时间片适中如10往往能在切换开销和响应性之间取得较好的平衡从而获得最高的吞吐率。这个实验让你亲身体会到操作系统调度器设计中的核心权衡Trade-off响应时间vs吞吐率。调整时间片就是调节这个权衡的旋钮。通过分析自己亲手收集的日志数据你对“调度策略影响性能”这句话的理解会比读任何教科书都深刻。6. 常见问题与调试心得在完成这个实验的过程中你几乎一定会遇到各种问题。我把一些常见的坑和解决思路分享出来希望能帮你少走弯路。1. 编译错误或内核无法启动这通常是因为代码修改有语法错误或者破坏了关键的内核数据结构。务必仔细检查你添加的fprintk语句确保括号匹配、分号结束、参数正确。建议每修改一个文件就单独编译一次那个文件使用make的部分编译功能确认无误后再链接整个内核。2. 日志文件没有生成或内容为空检查文件打开语句的位置确保open调用在init函数内且是在第一次fork()之前。太早由task0执行或太晚文件描述符无法被子进程继承都会导致问题。检查fprintk的实现确保它正确调用了sys_write并且使用的文件描述符通常是3是正确的。可以在fprintk里先用printk打印一些调试信息到控制台看看函数是否被调用。检查Bochs的配置文件确保虚拟硬盘镜像文件正确挂载并且有足够的空间/var目录存在且有写权限。3. 日志中出现不合理或重复的状态序列比如看到一个进程连续两个R事件中间没有J或者一个进程退出E后还有状态变化。这通常是因为埋点的位置不够精确。重复的J记录仔细检查schedule()函数。有时唤醒睡眠进程的代码块和因时间片到期而切换的代码块可能会对同一个进程的状态改变都记录一次J导致重复。需要理清逻辑确保每个状态变迁只记录一次。僵尸进程的状态变化确保do_exit()中在设置state TASK_ZOMBIE并记录E之后不会再有任何代码修改该进程的状态或尝试调度它除了最后的schedule()调用它不会再返回。4. 分析脚本计算的时间或指标不对时间戳jiffies的理解jiffies是系统时钟滴答数它的频率HZ在Linux 0.11中通常是100即每秒100个滴答。计算真实时间需要除以HZ。边界情况处理你的分析脚本需要妥善处理进程的第一次状态记录可能不是N和最后一次记录。对于在观察期开始时已经存在的进程如init进程和结束时还未结束的进程要决定如何计算它们的部分生命周期。调试内核代码就像侦探破案日志是你的线索。当结果不符合预期时耐心地、逐行地审查你添加的代码思考它在每种可能的执行路径下会产生什么记录再对比实际日志往往就能定位问题所在。这个过程虽然有时令人抓狂但却是理解内核并发和异步执行逻辑的绝佳训练。