第一次把 Linux 内核源代码完整拉下来解压的人，十有八九会在十分钟内关掉编辑器——七万多个文件、两千多万行代码、几百个架构目录铺在眼前，光是arch/底下就够劝退一整晚。但如果把"Linux 内核学习"当成一门需要动手的手艺，而不是一场靠通读完成的体力活，源代码其实是最诚实的朋友：所有文档里含糊其辞的地方，源码里都有确切答案；所有博客里互相矛盾的结论，源码里都只有一句实现。这篇东西想聊的就是怎么把 Linux 内核源代码真正读进去、编译起来、跳得动、断得住、验证得出来，而不是停留在"收藏了一堆教程"的状态。

这篇内容偏实战，适合三类人：写过驱动或做过内核模块、想补系统性认知的中级开发者；做性能优化或问题定位、需要从调用链层面找根的工程师；以及刚学完操作系统课程、想看看真实实现到底长什么样学生党（这里用"学生党"作泛指，不做任何身份关联）。阅读门槛大概是能看懂 C 语言里的指针和宏，知道进程、页表、系统调用这些概念，剩下的边读边补就行。

我不打算给你列一份"一个月读完内核"的计划表，那种东西基本没有执行力。我更想把这几年反复进出内核源码的经验拆成几块：读什么、怎么搭环境、从哪条主线走、四个大子系统的切入点、怎么用动态手段验证理解，以及那些踩过一遍就不想踩第二遍的坑。

1. 先把"读源代码"这件事定义清楚

内核源代码不是小说，不存在从头读到尾这回事。它更像一个运行了三十多年的巨型单体工程，每一行代码背后都挂着一个具体的历史问题、一次性能争执、一段兼容性妥协。所以"读"这个动作必须先被拆解：你是想搞清楚某个机制怎么运转，还是想定位某个现象的原因，还是想给某个子系统提补丁？三种目标对应三种完全不同的读法，混在一起就会变成无效浏览。

我见过太多人卡在第一步：打开kernel/sched/core.c，看到两千多行__sched_setscheduler()，硬着头皮往下读，读到第三屏注意力就散了。原因不是水平不够，是缺少"锚点"——你不知道这段代码是在哪个场景下被调用、为什么需要这么绕、绕开了什么问题。锚点只能从调用链和数据流上来，绝不是从逐行注释里来。

1.1 三种典型路线，先选一条走通

路线一：机制路线。选一个横向机制，比如"一个进程创建出来会经历什么"，然后沿fork()系统调用一路追下去：sys_clone→kernel_clone→copy_process→dup_task_struct→copy_mm/copy_files/copy_sighand。这条路线的好处是路径唯一、不依赖硬件细节、几乎全部在kernel/fork.c一个文件里完成，非常适合第一次建立"内核是怎么组织一次操作"的直觉。

路线二：子系统路线。直接切进内存管理或文件系统，从核心数据结构入手，反向找谁在读写它们。比如先把struct address_space、struct page、struct folio三者的关系捋清楚，再去看filemap_read()怎么把页缓存拼成用户态的一次read()。这条路线的信息密度最高，但前期陡峭，必须先啃数据结构。

路线三：问题驱动路线。手里有一个具体问题——OOM 杀进程、文件写入延迟抖动、某个驱动 probe 失败、上下文切换次数异常高——然后带着问题去找代码。这条路线效率最高、正反馈最快，缺点是需要一点运气：你得先有个能复现的问题。

我的建议是先走路线一，用两到三次完整追踪建立手感，再切路线二，路线三随时穿插。路线一练的是"看调用链"的眼力，路线二练的是"看数据结构"的眼力，两个能力都有了，路线三才是真正的享受。反过来先走路线二，多数人会在mm/目录里迷路，因为内存管理的代码里到处是跨架构的条件编译和长期演进留下的分支，缺少"这一条链是干什么用的"的前置认知，读起来就是在看天书。

1.2 版本和分支怎么定，别一上来就追最新

内核每两三个月一个版本，主线里每天都有几百个补丁进进出出。对读源码的人来说，追最新主线是纯粹的效率灾难：你今天刚读完一个函数，下周它可能被重构掉一半。更合理的选择是挑一个长期支持版本，把它的源代码当作基准，然后只在需要的时候去看上游的演进。

选择逻辑大概是这样：稳定长期支持分支的功能足够新，又不会天天变；版本号和线上服务器或你自己的实验机尽量对齐，调试时符号才对得上；如果你关注的是某个具体子系统，还要看它在这个版本里是不是正好处在大改期间——比如调度器在近版本里经历过一次核心算法替换，内存管理长期在把page往folio迁移，这两个方向上的代码在相邻版本之间差异会非常大，读之前最好先确认一下。

还有一点很多人忽略：分支的补丁历史本身就是最好的注释。当你搞不懂某段代码为什么这么写时，git log -L或者git blame一下就出来了，一个变量为什么要加锁、一个分支为什么要保留旧路径、一个看起来毫无意义的判空是不是在处理某种竞态，提交信息和讨论串里通常写得明明白白。我自己的习惯是，每读一个函数，只要发现它带有"奇怪"的写法，就顺手 blame 一眼，十次里有七八次能直接找到答案，比在脑子里推演快得多。

2. 环境准备：让源码可编译、可跳转、可断点

读内核源码最忌讳"只看不跑"。静态阅读能解决 60% 的疑惑，剩下的 40% 必须靠编译、断点、日志和跟踪来验证。所以环境这部分别偷懒，一次性搭好，后面几个月都受益。

2.1 源码目录的第一遍扫读

拿到源码树之后，先花二十分钟把顶层目录挨个看一遍，不求理解，只求建立空间感。arch/是架构相关代码，同一个机制在 x86 和 ARM 上往往有两套实现，读的时候务必确认自己在看哪一套；kernel/是调度、时间、信号、模块加载这些核心机制；mm/是内存管理；fs/是虚拟文件系统和具体文件系统；drivers/占了整棵树体量的一大半，但真正需要精读的只有跟你方向相关的那一小块；include/是头文件，要注意include/linux/和include/uapi/的区别，后者是对用户态暴露的接口定义；init/里只有几个文件，却是整个启动流程的入口；lib/放的是内核自己实现的数据结构和算法；scripts/里藏着链接脚本和一堆代码生成工具，理解构建过程时绕不开。

看目录的时候顺手做一件事：把MAINTAINERS里跟你关注子系统相关的条目扫一眼，能快速知道这个模块的代码分散在哪些目录、有哪些相关文件，比自己在树上瞎找高效得多。

2.2 编译配置：最小可用 + 保留调试信息

内核编译的默认配置通常是给发行版用的，选项又多又杂，编译一次动辄半小时以上，而且大量无关驱动会把索引文件撑到几个 GB。读源码场景下，配置思路是能跑起来 + 能调试 + 尽量少。

几个关键点：

• 用make defconfig或某个精简配置起步，然后手动关掉不需要的驱动类别。图形、声卡、无线、大量厂商专有驱动全部关掉，镜像能小一个数量级。
• 打开CONFIG_DEBUG_INFO，这是 gdb 能认符号的前提。近版本还需要配合选择调试信息格式，选错了会导致调试器加载符号失败。
• 打开CONFIG_DEBUG_INFO_DWARF5（或对应版本支持的格式）和CONFIG_GDB_SCRIPTS，后者会生成一套 gdb 辅助脚本，能直接lx-ps、lx-dmesg、lx-lsmod，比手动敲结构体偏移舒服太多。
• 打开CONFIG_KALLSYMS_ALL，保证内核里所有符号都能在/proc/kallsyms里看到，做 kprobe 和 ftrace 时非常依赖这个。
• 需要验证内存相关结论时临时开CONFIG_KASAN，但记住它会让性能和内存占用都显著变差，只用于排查特定问题，不要长期挂着。
• 打开CONFIG_DYNAMIC_DEBUG，之后可以用动态调试按文件、按函数、按行打开pr_debug，这是最省事的"给内核加日志"方式，不用改一行代码。

编译并行度有个经验公式：-j取min(CPU 核数, 内存 GB 数 / 2)。内核编译的单个编译单元内存峰值可以到 1.5～2 GB，16 GB 内存的机器上开-j16大概率会被 OOM killer 干掉一个cc1，然后报一堆莫名其妙的错误，让你以为是代码问题。稳妥一点，8 核 16 GB 就-j8，慢不了多少。

构建目录建议用O=分离出去，源码树保持干净，切换配置和清理都方便，也不容易把生成的中间产物误当成源码看。如果你会反复编译，装个编译缓存工具能省掉大量重复工作，第二次全量编译往往能压到几分钟。

2.3 索引与跳转：ctags、cscope、clangd 的组合拳

这是读内核源码体验差异最大的一环。纯靠grep也能读，但效率低得离谱，尤其是追踪一个函数被谁调用的时候。

ctags负责符号定义跳转，生成速度快，适合"从调用跳到定义"。内核里有大量同名函数、宏和架构特化版本，生成时记得加上对static函数和原型声明的支持，否则很多内部函数会缺索引。用通用版本（Universal Ctags）比老版本体验好，字段更全。

cscope负责"谁调用了这个函数"这类反向查询，是追踪调用链的核心工具。生成索引时必须加-k参数，把系统头文件目录排除掉，否则它会把整台机器的/usr/include也扫进去，索引体积翻好几倍还全是干扰项；再加上-q生成倒排索引，查询会快一个量级。索引文件在内核这种体量下能到几百 MB 甚至上 GB，机器内存别太小。

编辑器的选择就看习惯，Vim 配 cscope 是经典组合，跳转、查找调用者、查找字符串都在一个交互界面里完成。如果你更习惯现代编辑器，那就走 LSP 路线：先完整编译一遍，然后跑内核自带的脚本生成compile_commands.json，之后语言服务器就能给出精确到编译参数级别的跳转和补全。这两条路可以并存——LSP 负责日常编辑的准确跳转，cscope 负责大范围的反向搜索，互补得很。

提示：任何索引工具在内核上都不是完美的。宏拼接出来的函数名、函数指针赋值、static inline定义在头文件里的实现，跳转经常失效。这种情况下别跟工具较劲，直接grep具体字符串，或者去.config里确认这个代码路径到底有没有被编译进去。

2.4 QEMU + gdb：把断点打在你读的那一行

光看代码永远有一层隔膜，加上断点之后，整个理解方式会变。虚拟机启动一个自己的内核，配上调试器连上去，你就能在start_kernel的第一行停下，然后一步一步走完整个启动流程。

关键参数只有几个：启动时把调试端口打开、让虚拟机在第一条指令处暂停、串口输出重定向到终端。挂载调试器时指定带调试信息的vmlinux，然后连上调试端口。

必须加nokaslr。内核地址随机化打开的时候，每次启动代码加载的基址都不同，调试器里的符号地址和实际运行的地址对不上，断点会时灵时不灵，这个坑至少浪费过我两个晚上。加了这个参数，地址固定，断点一打一个准。

这套环境搭好之后，用法就很多了：想验证某个初始化函数真的在start_kernel里被调用，就在那里下断点看调用栈；想搞清楚一个数据结构在内核启动早期是什么样子，就停在那里打印结构体内容；想跟踪一次系统调用的完整路径，就在入口下断点，配合step和finish走。比读十遍代码管用。

3. 一条贯穿式主线：从加电到第一个用户进程

如果只允许选一条主线把内核源代码读一遍，我选启动流程。原因很实在：启动是唯一一条把所有子系统都串起来的路径。内存管理在建页表，调度器在初始化运行队列，中断控制器在注册处理函数，文件系统在挂载根分区，最后所有东西汇成一次execve，把第一个用户态进程拉起来。走完这一遍，你对整棵树的空间感会完全不同。

3.1 引导阶段的几个必要落点

x86 的启动路径大致分三段：引导程序把内核镜像加载到内存并跳到入口，压缩镜像里的解压代码把真正的内核解出来，真正的内核从架构相关的汇编入口进入 C 世界。读的时候不需要逐行啃汇编，但有几个落点必须找准：镜像头部的结构定义（理解引导程序是怎么找到入口点的）、解压阶段的 C 入口（这里已经开始有少量 printk 了）、架构入口到start_kernel之间的那几个调用（页表初步建立、栈切换都在这段发生）。

这一段代码的特点是汇编和 C 交错、跨架构分支多，硬读会很痛苦。更有效的做法是先看调用顺序，再看每一步做了什么：用一个表格把"地址空间准备 → 早期页表 → 切换到虚拟地址 → 建立完整页表 → 跳进架构无关代码"这条时序列出来，然后针对每一步只读对应的那几十行。我当年在这段上走的最大弯路就是试图理解每一条汇编指令，结果花了两天时间搞清楚的东西，后面半年一次都没用到。

3.2 start_kernel 到 rest_init：初始化顺序背后的依赖

start_kernel()是整个内核的"主函数"，它在init/下那个文件里，全篇基本就是一串函数调用，看起来平淡，实际上是整个内核初始化顺序的权威说明。这里有个非常值得花时间的点：为什么是这个顺序。

举几个例子就能体会到。设置每 CPU 区域必须在任何可能访问 per-CPU 变量的代码之前；初始化调度器必须在创建任何内核线程之前，因为线程创建本身就要走调度器；初始化中断必须在注册中断处理之前；控制台初始化必须尽量早，否则前面所有的printk都只进缓冲区不输出。这些依赖关系没有一份完整文档写着，全都隐含在顺序里。你把每一行往前推一步想想"如果调换会怎样"，理解就会深一层。

再往后，start_kernel()最后调用rest_init()，这里创建了两个关键的内核线程：一个最终演变成 pid 1 的 init 进程，负责执行用户态的第一个程序；另一个是内核线程的父线程，之后所有内核线程都从它 fork 出来。这一段代码的细节很容易看漏——kernel_thread()创建出来的线程并不是直接执行init，而是先经过一个kernel_init()的中间函数，在里面完成设备初始化、执行initcall、最后才去execve用户态程序。这个中间层是理解"内核什么时候真正开始对用户可见"的关键。

3.3 initcall 分级机制与链接脚本的配合

内核里绝大多数模块的初始化都不是硬编码在start_kernel()里一个个调用的，而是通过initcall机制自动执行。用module_init()注册的初始化函数，本质上是往一个特定段里塞了一个函数指针，链接阶段所有同级别的指针会被排在一起，启动时按级别顺序遍历执行。

这个机制有几个非常值得读的细节。级别是有严格顺序的，从最核心的到最晚的，中间依次是核心、架构相关、子系统、文件系统、根文件系统、设备和最晚级别，其中module_init()默认落在设备级别。这个顺序解释了为什么驱动可以在probe里放心调用文件系统接口——文件系统的 initcall 级别更早。链接脚本里能看到这些段的定义和排序方式，init/main.c里能看到遍历逻辑和do_one_initcall()的实现，两处对着看，机制就完全透明了。

顺带说一个只有读过这段代码才会注意到的点：__init标记的函数和它们的段在启动完成后会被释放掉，free_initmem()一调，那部分内存就还给系统了。这解释了为什么驱动代码里不能用__init函数指针留作回调——人家内存都回收了，再调用就是野指针。

3.4 用日志验证你对顺序的理解

光读代码容易自我欺骗，觉得自己懂了。验证方法特别便宜：加一个内核启动参数，让每个 initcall 执行时打印自己的名字和耗时。跑一遍启动，你会看到成百上千行初始化记录，按级别排得整整齐齐。

这时候你就可以做真正的验证了：随便挑一个你在代码里看到的初始化函数，看它出现在日志的哪个位置、它的耗时是多少、它有没有因为依赖未满足而失败。如果要更细，就在do_one_initcall()里临时加几行打印，或者用动态调试打开特定文件的调试输出。这种"预测—验证—修正"的循环是读内核最高效的方式，一次循环胜过读十页代码。

4. 四大子系统的切入点和读法

主线走完之后，就该往纵深处切。内核子系统很多，但对大多数开发者来说，真正需要吃到源码级别的就四个：内存管理、进程调度、文件系统、驱动与中断。每一个都能单独写一本书，下面只讲怎么切进去，也就是找哪个文件、先看哪个结构、从哪个函数进。

4.1 内存管理：从 struct page 到缺页处理

内存管理的代码在mm/和架构相关的页表代码里，体量大、演进快，直接读很容易崩。我的建议是分三层，从下往上。

第一层是物理页的描述。整个内存管理围绕页这个基本单位展开，早期版本用一个结构体描述物理页，近版本在往更大的粒度（folio）迁移，理解这个迁移的动机很有价值：减少大页场景下逐页处理的开销，同时让"这个页是复合页的一部分"这件事在类型层面就说清楚。读这一层时重点是标志位和引用计数，它们是后面所有逻辑的基础。

第二层是分配器。伙伴系统负责物理页块的分配和合并，free_area按阶组织空闲链表，分配时向上找、释放时向下合，这套逻辑在mm/page_alloc.c里，核心就几百行，值得完整读一遍。再往上是 slab 分配器（现在默认是 SLUB），负责小对象的缓存，kmem_cache和每 CPU 的空闲链表是关键。这里我有一个很实用的观察：读分配器最大的收获不是会用kmalloc，而是理解"为什么内核里到处都在谈 NUMA 和 CPU 亲和"——所有分配路径里都有节点和 CPU 的考虑，看懂了这些分支，线上性能问题的很多现象才有解释。

第三层是缺页处理，也就是一次访问未映射内存时内核干了什么。入口在架构相关的异常处理里，最后落到mm/memory.c的handle_mm_fault()，然后按页表层级一层层往下，最终分三种情况：匿名页第一次访问就分配零页，文件映射页去读页缓存或者发起 IO，交换出去的页读回来。这条路径是理解"内存到底什么时候真正分配"的最佳入口，也解释了为什么malloc之后free之前的 RSS 可能是 0。

读这一层时，强烈建议配合虚拟机做实验：写个小程序不断malloc和读写，同时在handle_pte_fault()上下断点，亲眼看看每一步页表是怎么填的。这种验证比任何图解都可靠。

4.2 进程调度：task_struct、调度类与上下文切换

调度器的代码在kernel/sched/下，按调度类和核心逻辑分了多个文件。读法上抓三个点。

第一个是进程描述结构。struct task_struct是内核里最复杂的结构体之一，打开之后几百个字段会让人直接放弃。别硬看，用检索的方式读：先找state、prio、sched_entity、mm、active_mm、files、nsproxy这几类最关键的字段，每一类都想清楚"它属于进程的哪个方面"。剩下的大量字段可以在用到的时候再回来查，这个结构体本来就是当字典用的。

第二个是调度类抽象。内核里没有唯一的调度算法，而是定义了一套调度类接口，实时进程、普通进程各有一套实现，核心调度函数按优先级从高到低依次询问各个类。这个设计非常值得学习：它用一层间接把"策略"从"机制"里剥出来了。读的时候重点看接口定义，以及普通进程调度类里那几个核心方法——入队、出队、选下一个。

第三个是上下文切换。从__schedule()进去，到最终切寄存器、切栈，中间要处理的事非常多：更新调度统计、处理抢占标志、切换页表（switch_mm）、切换寄存器状态。近版本的调度器在普通进程的公平性算法上做过一次替换，用更强调延迟公平的算法取代了之前的方案，如果你读的是新版本，别拿老文章里的公式硬套，一定以手上的代码为准。

4.3 文件系统：一次 open 到底走了多少层

VFS 是内核里设计最优雅的部分之一，也是最容易看懂的部分之一，因为它有非常清晰的抽象层次。

读之前先记牢四个核心对象：超级块描述一个已挂载的文件系统实例，inode 描述一个文件在文件系统层面的元数据，dentry 是目录项缓存，file 描述一个已打开的文件，持有当前位置和读写模式。这四者的关系用一张草图就能画清楚，画完之后再去看代码。

然后选一条最简单的路径追：open()一个文件。路径大概是系统调用入口 → 路径查找（这一层最复杂，要处理相对路径、符号链接、权限检查、中间目录不存在的情况）→ 找到 dentry 之后判断是否需要创建 → 调用具体文件系统的打开方法 → 分配struct file并建立关联。追完这一遍，你会对"文件系统是怎么把通用接口和具体实现解耦的"有非常具体的认识。

再往下就是页缓存。缓冲读写走的不是直接读磁盘，而是先看页缓存里有没有，有就直接拷贝，没有就发起 IO 并等待。这条路径在mm/filemap.c里，filemap_read()是入口，逻辑不复杂但涉及锁、预读、错误处理，值得细读。理解了页缓存，很多现象就有答案了：为什么顺序读和随机读的差异那么大、为什么fsync之后延迟会抖、为什么内存紧张时写入会变慢。

4.4 驱动与中断：probe 时机和上下半部

驱动代码占了内核源码的绝大部分，但不需要全读——读懂一个总线上的一个简单设备驱动，其他都是同一套路。

关键点是设备与驱动的匹配时机。驱动注册到总线之后，并不会立刻初始化，而是等设备出现（或者设备先出现、驱动后注册）触发匹配，匹配成功后调用驱动的probe。这个时机比很多人想象中晚，也解释了为什么驱动里不能假设某个资源一定可用。读这段代码时要把总线、设备、驱动三个结构的关系捋清楚，再顺着driver_register()往下看匹配流程。

中断这部分，核心是上下半部的划分。上半部（硬中断处理）要求快、不能睡眠、不能做耗时操作，它一般只做"确认中断、读状态、把活推给下半部"。下半部有几种机制，软中断适合网络和块设备这类高频路径，工作队列适合可以睡眠的延迟任务。读的时候注意看中断描述符的组织方式、共享中断怎么处理、以及线程化中断的引入动机——后者是为了让大部分处理运行在进程上下文，可以用更丰富的同步原语。

5. 动态验证：别只靠"读"，让内核自己说出调用链

静态阅读的天花板很快就到：你能看懂代码做了什么，但不知道它在真实运行时到底走哪条分支、频率如何、耗时多少。这时候必须上动态手段。

5.1 ftrace 与 function_graph 的正确用法

ftrace 是内核自带的功能，不需要额外工具，挂上调试文件系统就能用。最实用的模式是函数图模式，它能把函数的调用层级和耗时直接打出来，读递归或者深调用链的时候简直是作弊器。

用法上有几个细节决定体验。函数过滤很关键，内核有几十万个可跟踪函数，全开会把缓冲区瞬间冲爆，一定要先用过滤器圈定几个函数。另外不是所有函数都能被跟踪，被内联掉的、标了禁止跟踪的、以及编译器优化掉的都不行，遇到"明明调用了却抓不到"的情况，先怀疑内联，再怀疑优化等级，别怀疑工具坏了。

在虚拟机上跑的时候，可以把跟踪结果直接打到串口，配合启动参数就能看到整个启动过程的函数调用图。我第一次这么干的时候，盯着满屏缩进的调用树看了半小时，那种"原来它是这么一层层下来的"的感觉，比读任何架构文档都强烈。

5.2 kprobe 事件与 perf 的组合

ftrace 只能跟踪已经在代码里埋好的点，kprobe 可以在任意指令地址上动态埋点，还能读取寄存器和内存。把它做成事件之后，就能和性能工具联动，统计某个函数被调用多少次、参数分布如何。

实际用法是：先在内核符号表里找到目标函数，然后往动态事件接口里写一条规则，指定在函数入口或返回处抓哪些寄存器。抓到的数据可以读事件计数，也可以直接用性能工具采样。这一招在定位"某个函数被异常频繁调用"这类问题时极其有效，因为它不需要改代码、不需要重启、不需要重新编译。

5.3 写一个最小模块验证你的结论

最后这招是最狠的：自己写一个模块，直接调用你怀疑的内核接口，打印结果。比如你想确认某个分配函数在给定参数下会落到哪条分支，与其在代码里推演，不如写十行代码调一次，把返回值、标志位、当前进程信息全打出来。

写模块的时候有几个规矩要守：注册和注销必须成对，出错路径要清理干净，否则会留下垃圾；打印信息里带上当前进程名和 pid，多任务环境下不带这两样根本分不清谁是谁；调试用的模块不要在正式环境常驻，加载完验证完立刻卸载。这套习惯养成之后，你验证一个猜想的时间成本大概就是五分钟，比在代码里绕半小时强太多。

6. 踩坑记录与排查速查

下面这些是我这几年反复遇到、也见过别人反复遇到的问题，整理成表，方便对照。

6.1 跳转工具失效的几类原因

这几种情况没有哪个工具能彻底解决，本质原因是 C 语言的静态分析边界。我的经验是：遇到跳转失败，先问"这段代码真的会被编译吗"。内核里大量代码是条件编译的，你正在读的那段可能在你当前的配置下根本不存在，这时候所有的跳转和断点都毫无意义。养成先看一眼配置、再看代码的习惯，能省掉大量无效劳动。

6.2 调试环境对不上的典型症状

表格里第一条我踩得最多。因为症状太迷惑人了：断点设了，程序也跑过去了，就是不停。你会开始怀疑代码路径不对、怀疑函数没被调用，其实只是地址偏了几百 MB。现在我的习惯是，任何调试环境搭好之后第一件事就是在start_kernel上下一个断点，确认能停住，再往下做任何事。

6.3 阅读节奏与笔记方法

最后说点软的，但我觉得比工具更重要。

别贪多。一个子系统读透，胜过五个子系统各读个开头。我见过太多人列了长长的清单，最后每个都停在"数据结构看完了"这一步。真实情况是，一个子系统你要能说清楚它的核心数据结构、主要调用链、并发假设、失败路径，才算入门，这四样东西任何一个没搞明白，遇到实际问题还是抓瞎。

笔记只记三类东西。第一类是数据结构关系图，自己画，别抄别人的，画的過程就是理解的过程。第二类是调用链，带文件行号，方便回查。第三类是你自己的疑问和验证结果，比如"猜测这里走的是快路径，断点验证：走的是慢路径，原因是 X"。第三类最有价值，因为它记录的是你的认知修正过程，过半年回来看，比任何教程都亲切。

善用版本对比。当你不理解某段代码为什么这么写，去看看它在两个版本之间怎么变的，八成能猜到原因。如果一次提交里同时改了代码和注释、还附带了测试，那基本就是这个改动的完整上下文。这个习惯养成之后，读代码从"猜"变成"查"，效率完全不是一个量级。

给阅读设时间盒。内核源码读不完，这是客观事实。我的做法是每次只给自己定一个具体问题，比如"今天搞明白read()从系统调用到页缓存的完整路径"，时间到了就停，不管有没有完全搞懂，记下卡在哪里，下次接着来。这样既能保持进度，又不会因为"又没读完"而放弃。

说个我自己的体会收尾。刚开始读内核源码那阵子，我总想着要"系统地学一遍"，结果三个月过去，脑子里全是零散的片段，什么也没真正掌握。后来改变策略，每次只带着一个具体问题进去，读完必须能回答这个问题，答不上来就去做实验。一年下来，虽然"读过的代码"比例依然很低，但解决实际问题的能力是实打实涨了——能被一个问题带着走进源码深处，再带着答案走出来，这个过程本身就是最好的学习方式。