两大职责，四大抽象

• 裸机上跑单个程序完全不需要 OS；一旦要同时跑第二个，四个问题立刻爆发：谁先用 CPU、内存怎么分才不互相踩、磁盘数据会不会搅在一起、一个程序崩了会不会把另一个带走；
• 复用是 CPU 按时间切片、内存按空间分割，抽象是把硬件包装成干净接口。四大抽象各给一个幻觉：进程「我独占处理器」、地址空间「我独占内存」、文件「存储是有名字的字节流」、系统调用「硬件是一组函数」。

前半程：按键怎么进来

• 键盘产生硬件中断，CPU 放下手头的活跳到内核的中断处理程序（第02章）。
• 字符经终端子系统（tty）送达 shell——它一直阻塞在 read() 上睡觉，此刻被唤醒，拿到你输入的一行（第09章）。

后半程：程序怎么跑起来

shell 解析出 "ls"
    ↓ fork() 复制出子进程，execve() 加载 /bin/ls   → 第03章：进程
内核解析 ELF、建立新的地址空间与页表                → ELF=可执行与可链接格式；第06/07章
    ↓ 调度器从就绪队列里挑中它，放上 CPU            → 第04章：调度
ls 调 openat()/getdents() 读目录项                  → 第08章：文件系统
    ↓ 数据若命中 page cache，一次磁盘都不用碰
write() 把结果写到终端                              → 第09章：I/O
    ↓ exit() 退出，父进程 shell 用 wait() 收尸      → 第03章
shell 打印下一个提示符，回到 read() 继续睡

一张挂靠表

柱子之外的五章

• 第02章是地基：硬件特权级划出的内核/用户边界，是三种幻觉能够成立的前提——没有它，任何程序都能拆穿把戏。
• 第10章是把幻觉再包一层：虚拟机给你「整台机器」的幻觉，容器给你「独占操作系统」的幻觉——虚拟化思想的递归应用。
• 第11章是让幻觉之间互不穿透：隔离做不严，共享就变成漏洞；
• 第12章是把像素也纳进来：图形栈与窗口系统，桌面那一侧的「谁能画到屏幕上」同样是一次资源分配；
• 第13章把前面的机制亲手写一遍（微项目），第14章是路线图。

一条命令看穿 cat

$ strace -e trace=openat,read,write cat /etc/hostname
openat(AT_FDCWD, "/etc/hostname", O_RDONLY) = 3
read(3, "mybox\n", 131072)                 = 6
write(1, "mybox\n", 6)                     = 6

• cat 的本质就是 openat + read + write 三次系统调用，其余全是 libc 的启动开销。以后遇到「这程序到底在干什么」「它为什么找不到配置文件」，先 strace 再说——它把猜测变成事实。
• strace -c ls 换成统计表：每种系统调用的次数与耗时一目了然。想看某个程序是不是在疯狂 syscall，这一条就够。

顺手能验证的两件事

• 库函数 ≠ 系统调用：一个做 1000 次 malloc/free、100 次 printf 的程序，strace -c 下 brk 只有几次、write 只有 1 次——libc 在用户态攒缓冲、管内存池，凑够了才进内核（第 02 章）。
• shell 内建命令不走 exec：strace -f -e trace=execve bash -c ls 能看到 execve("/usr/bin/ls",…)，而 bash -c cd 一次都不多——因为 cd 必须是内建的（子进程改自己的工作目录影响不了父进程，第 03 章）。

四个每章都会用到的入口

$ cat /proc/self/status      # 这条命令自己的 PCB 摘要：内存、线程数、身份、限额
$ cat /proc/self/maps        # 地址空间布局：text/heap/stack/共享库 → 第 06 章
$ ls -l /proc/<pid>/fd       # 它打开了哪些文件/socket   → 第 08、09 章
$ cat /proc/<pid>/task/*/wchan  # 每个线程卡在哪个内核函数上 → 第 05 章

• 其中 wchan 是被严重低估的一个：进程「卡住不动」时它直接告诉你线程停在哪个内核函数里——全是 futex_do_wait 基本就是锁的问题，全是 io_schedule 就是在等 I/O。
• /proc/self/maps 连跑两次，你会发现栈和堆的地址每次都不同——那是 ASLR 在随机化布局（第 06、11 章），也顺带证明了「你看到的每个地址都是虚拟地址」。

亲眼看一次：strace

$ strace -e trace=openat,read,write cat /etc/hostname
openat(AT_FDCWD, "/etc/hostname", O_RDONLY) = 3
read(3, "mybox\n", 131072)  = 6
write(1, "mybox\n", 6)      = 6

• strace 把进程与内核的全部对话摊在眼前：cat 的本质就是 openat+read+write 三次系统调用。以后任何「这程序到底在干什么」的疑问，先 strace 再说——它是把本页概念变成可观察事实的第一件工具。

定时器：海量「X 时间后做 Y」怎么高效管

• TCP 重传超时、sleep()、keepalive、看门狗、I/O 超时（第 09 章）——系统里同时挂着成千上万个定时器。逐跳扫一遍全部会把心跳拖垮，所以用时间轮或最小堆组织，每跳只碰「最近该到期」的那几个。
• 分两档精度：低精度定时器挂在 tick 上（毫秒级，便宜，绝大多数超时够用）；高精度定时器 hrtimer 直接编程硬件比较器（纳秒级，给多媒体、实时任务用）——精度按需付费，和第 09 章 io_uring「省掉每次系统调用」一样，都是把开销花在真正需要的地方。

这条分界线真正决定的是：一个驱动崩了会怎样

• 所以选型不是「哪个更先进」，而是你更怕什么：怕慢就宏内核，怕整机停摆就微内核。汽车刹车、医疗设备、飞机娱乐系统用 QNX，不是因为它快，而是因为一个坏驱动不该让整车失控。
• 混合内核（macOS/iOS 的 XNU、Windows NT）是历史妥协的产物：XNU 里 Mach 微内核负责 IPC 与虚拟内存，BSD 层与驱动仍在内核态——「设计上是微内核，工程上把性能敏感的部分搬回了内核」，这几乎是所有商业微内核尝试的共同结局。

每一棒都在做同一件事：搬下一棒，再跳过去

• 固件（UEFI/BIOS）：唯一「一通电就已经在内存里」的代码——它固化在主板闪存上。它要做的第一件苦活是初始化内存控制器，因为在那之前 DRAM 根本不能用；这期间固件只能把 CPU 的 Cache 当内存使（cache-as-RAM）。「先有鸡还是先有蛋」在开机这一刻是真实的工程问题。
• bootloader（GRUB 等）：住在磁盘上，负责把内核镜像与 initramfs 读进内存并跳进去。它还要处理「内核在哪个分区、用什么参数」这些只有它知道的事。
• 内核：初始化子系统、挂载根文件系统，然后执行 /sbin/init——这是内核做的最后一件「特殊」的事，之后它就退回幕后，只在系统调用/中断/异常时被叫醒。
• init（systemd）：按依赖关系并行拉起服务，直到登录界面。

两种「切换」的量级差在哪

• 把两者混称是很多性能误判的起点：不少资料把系统调用也叫 context switch，读者因此以为「syscall 极贵、要拼命避免」。实际上裸系统调用（如 getpid）在百纳秒量级，而真正的进程切换要付缓存与 TLB 变冷的账，量级差一两个数量级。先分清付的是哪种成本，再谈优化。
• Meltdown 之后模式切换确实变贵了：KPTI 让每次进出内核都要切页表，PCID（给 TLB 项打进程标签，见 05 章）把损失压了回来但没有归零。「syscall 便宜」这个前提在 2018 年被削弱过一次——这也是 io_uring 那种「批量提交、甚至零 syscall」的接口在此后几年集中出现的时代背景。

「进程」到底由几样东西构成

• 一份地址空间（一棵页表，05 章）——这是隔离的载体，也是进程比线程贵的全部原因。
• 一个或多个执行流（每个有自己的寄存器现场和栈）。只有一个时我们习惯说「单线程进程」，但在 Linux 眼里进程和线程是同一种东西（都是 task），区别只在创建时选择共享什么。
• 一堆内核记录的资源：打开的文件描述符表、当前工作目录、信号处理设置、用户/组身份、资源限额、cgroup 归属。这一条最容易被忽略，却是很多 bug 的现场——「子进程为什么继承了父进程的 fd」「为什么 exec 之后环境变量还在」，答案都在这里。
• 验证很直接：ls -l /proc/<pid>/fd 看它的 fd 表、cat /proc/<pid>/status 看身份与限额、ls /proc/<pid>/task/ 看它有几个执行流。「进程」这个抽象在 procfs 里是逐项摊开的。

ps 的每个字母该往哪个方向查

• 最常见的误判是把 S 当异常：一台正常服务器上绝大多数进程都是 S——它们在等网络、等定时器、等输入。「进程状态是 S」本身不含任何信息量。
• 第二常见的误判是把「卡住」一律当 D：等锁的线程是 S 而不是 D（04 章有），所以死锁在 ps 里完全看不出来。D 状态特指卡在不可中断的内核路径上，几乎总是指向块设备或网络文件系统。

那个「空隙」里到底能做什么

pid = fork();
if (pid == 0) {                    // ← 子进程，此刻还是父进程的副本
    close(1); open("out.txt",...); // 重定向：把 fd 1 换成文件  → shell 的 >
    dup2(pipefd[1], 1);            // 接管道                   → shell 的 |
    setenv("LANG","C",1);          // 改环境变量
    setuid(nobody_uid);            // 降权（服务器 fork 出工作进程的标准动作）
    chdir("/srv"); umask(077);     // 改工作目录、文件权限掩码
    execve("/bin/ls", ...);        // ← 到这里才换成新程序，上面的改造全部保留
}

• 关键在于：这些改造用的都是普通的、独立的系统调用，不需要「创建进程」这个 API 去预见并提供参数。一个 spawn(程序, 参数, 重定向表, 环境, uid, cwd, umask, ...) 的大函数永远追不上人们想改的东西。fork/exec 把「创建」和「配置」解耦，换来的是无限的可组合性——这是 Unix 设计里最常被引用的一个例子。
• 代价也真实：posix_spawn 和 Windows 的 CreateProcess 选了相反的路（一步到位、参数一大堆），在没有 COW（写时复制）的系统上、或者内存极大的进程里反而更合适——fork 一个占 100 GB 的进程即使有 COW，光复制页表也要花时间。所以 JVM、Go 这类大堆运行时启动子进程时更倾向 posix_spawn／vfork 路线。

贵在哪：直接成本只是零头

• 直接成本：保存/恢复寄存器、换内核栈、切页表基址寄存器。这部分是几十条指令，真的不贵。
• 间接成本（大头）：新进程的数据不在 Cache 里、映射不在 TLB 里，接下来是一连串 miss，要跑一段时间才「热」起来。所以切换的代价不是一个固定数字，而是「之后那段时间跑得更慢」——这也是它难以准确测量的原因：账不记在切换那一刻。
• 由此得到一条实用推论：切换频率比单次成本更值得关注。vmstat 1 的 cs 列（每秒切换次数）在近乎空闲的系统上也有每秒一两百次；真正的问题是它涨到几万甚至几十万——那通常意味着锁争用严重、或线程数远超核数在互相踩踏。

两条技术路线：有栈 vs 无栈

• 有栈协程(stackful，如 goroutine、fiber)：每个协程配一个独立的用户态栈，切换 = 换栈指针 + 存恢复寄存器。可在任意调用深度挂起(哪怕是深层库函数里)，写法和普通同步代码一模一样；代价是每协程都要占一份栈内存。
• 无栈协程(stackless，如 async/await、C++20 coroutine、Rust async)：没有独立栈，编译器把协程函数改写成状态机，局部变量存进一个堆上的状态对象，只能在编译期标出的 await 点挂起。省内存、可内联，但「能挂起的位置」被语法限定，且挂起点会顺着调用链一路传染(见下一卡「函数染色」)。

选型：按「数据量 × 是否跨机 × 要不要边界」三问定

• Unix 域 socket 是最被低估的一个：语义和网络 socket 完全一致（同一套 API，换个地址族），但不走协议栈、不算校验和，延迟和吞吐都比走 loopback 好；还能传递文件描述符和对端凭证（SCM_RIGHTS／SO_PEERCRED）——这两样是纯网络 socket 做不到的，也是 systemd 的 socket 激活和容器运行时能把 fd 交接给别人的基础。
• 共享内存最快，但它只解决「搬运」不解决「协调」：数据不经内核拷贝，代价是同步全靠你自己（04 章那一整章的内容都得自己上）。所以经验法则是：先用 socket 写对，压测证明拷贝真的是瓶颈，再上共享内存——和「先用锁再考虑无锁」是同一条纪律。

handler 里几乎什么都不能做

• 信号 handler 可能在任意一条指令之后插入执行——包括在 malloc 正持着它的内部锁的时候。此时 handler 里再调 malloc 就是自己等自己，直接死锁。同理 printf（stdio 有锁和缓冲）、几乎所有标准库函数都不安全。可安全调用的只有 POSIX 明列的异步信号安全函数（write、_exit、signal 等，man 7 signal-safety 有完整清单）。
• 所以正确姿势只有两种：① handler 里只设一个 volatile sig_atomic_t 标志位，真正的活留给主循环；② 用 signalfd（或自己造 self-pipe）把信号变成一个可以在 epoll 里等的 fd——信号从「随时打断你」变成「主循环里的一个普通事件」，这才是现代服务处理信号的标准做法。
• 还有一条容易忽略的：信号会打断阻塞中的系统调用。glibc 下用 signal() 注册的 handler 默认带 SA_RESTART，被打断的 read 会自动重启；只有用 sigaction 且不设该标志，才会拿到 EINTR 需要自己重试。「所有 syscall 都要循环处理 EINTR」这条老教条，在默认路径上其实不成立——但写库代码时仍要防着，因为你不知道调用者怎么注册的。

五个指标，两两互相拉扯

• 周转与响应是两个「快」，最容易被混为一谈：一个编译任务你只关心它什么时候编完（周转），一次按键你关心的是屏幕多快有反应（首次响应，之后慢点没关系）。同一个调度器不可能两头都最优——让短任务优先能压低平均周转，但会让长任务饿死；轮转能保证人人有响应，但增加了每个任务的完成时间。
• 由此就明白为什么调度器有一大堆而不是「最好的那一个」：它们只是在这张表里选了不同的加权。Linux 提供 SCHED_OTHER（EEVDF，重公平与延迟）、SCHED_FIFO/RR（重可预测）、SCHED_BATCH（重吞吐）、SCHED_IDLE（只吃剩饭）——同一个内核里并存四套策略，就是因为没有万能答案。

四个算法是一条推导链，不是四个并列选项

FCFS  先来先服务
  ✗ 一个长任务堵住所有短任务（护航效应）
        ↓ 「让短的先跑」
SJF   短作业优先  —— 平均周转可证明最优
  ✗ 要预知运行时间（不可能）  ✗ 长任务饿死
        ↓ 「谁都别久等」
RR    时间片轮转  —— 靠时钟中断强制轮转，响应有上界
  ✗ 片太小切换开销吃掉 CPU   ✗ 片太大退化回 FCFS
        ↓ 「任务本来就不平等」
优先级
  ✗ 低优先级饿死  ✗ 优先级反转
        ↓ 「用行为动态定级」→ MLFQ →「按虚拟时间记账」→ CFS/EEVDF

• 读这条链的正确方式是盯着每个 ✗：每个算法的缺陷正是下一个算法的设计动机，而真实调度器（MLFQ、CFS、EEVDF）是从这些残留矛盾里长出来的缝合体。背四个算法的名字没有用，认得出「这个问题当年是谁暴露的」才有用。
• SJF 最优但不可实现这一点值得单独记住：它给出了理论下界，真实调度器只能用历史预测未来（最近 CPU 用得多的，猜它接下来还会用得多）。「用过去猜未来」几乎是所有在线算法的唯一武器——分支预测（组成原理页）、页面置换（06 章）、缓存淘汰全是这一招。

不预知运行时间，却能逼近 SJF：靠观察行为

• MLFQ 的洞察是：「短任务」和「交互任务」在行为上有共同特征——它们很快就主动让出 CPU。所以不必预知任何东西，只看「你有没有用完时间片」：用满了（像 CPU 密集型）就降级，主动让出了（像交互型）就留在高层。用可观察的行为代替不可知的意图，这是整个算法的灵魂。
• 规则一旦公开就会被利用，所以朴素 MLFQ 有两个洞，各有补法：① 长任务被永久饿死 → 周期性把所有任务提升回顶层（也顺带适应「任务行为会变」）；② 进程可以作弊——在时间片快用完时故意让出一下，就能一直赖在高优先级 → 改成统计累计CPU 时间而非单次是否用满。
• 这两个补丁的思路值得单独带走：任何「按行为给待遇」的机制都会被行为伪装攻击，防御是「看累计而不看单次」。同样的模式出现在限流（令牌桶而不是看单次请求）、信誉系统、乃至 06 章的页面访问位近似里。

CFS 的核心只有一个变量：vruntime

• vruntime = 实际运行时间 × (基准权重 / 自己的权重)。调度器永远挑 vruntime 最小的跑（用红黑树维护，取最左节点）。权重大的任务，vruntime 涨得慢，于是能跑更久才被换下——「公平」被定义成「让所有任务的 vruntime 尽量接近」，而不是「时间平均分配」。一个变量就把优先级、公平、时间片长度全统一了，这是 CFS 设计上最漂亮的地方。
• nice 值通过一张权重表映射：nice 0 = 1024，每降一级约 ×1.25（5→335、10→110、15→36、19→15）。这张表直接预测 CPU 份额，四档全部吻合（两个死循环钉在同一个核上，观测 10 秒）：

  nice 0 vs nice  5  →  75.4% / 24.6%   （权重比 1024:335 = 3.06:1，3.1:1）
  nice 0 vs nice 10  →  90.3% /  9.7%   （1024:110 = 9.31:1，9.3:1）
  nice 0 vs nice 15  →  96.7% /  3.3%   （1024:36  = 28.4:1，29.3:1）
  nice 0 vs nice 19  →  98.6% /  1.4%   （1024:15  = 68.3:1，70.5:1）

  这组比例只取决于权重表，不因机器而异——想验证自己是否真懂 nice，就看能不能提前算出这四行。

抢占能不能发生，取决于「此刻在哪」

• 用户态代码：Linux 上一律可抢占——时钟中断到了就能换人，所以一个用户态死循环绝不会卡死系统。这是「Linux 是抢占式的」这句话的准确范围。
• 内核态代码：能不能被抢占是编译配置（PREEMPT_NONE / VOLUNTARY / PREEMPT / PREEMPT_RT）。配置成不可抢占时，一段长内核路径会一直跑到主动让出为止——这就是「用户态明明可抢占，实时性还是不够」的根源。
• 关了抢占或关了中断的临界区：任何配置下都不可抢占。PREEMPT_RT 补丁的核心工作就是把这些段尽量切碎（把大量自旋锁换成可睡眠的互斥锁），把最坏延迟从毫秒级压到微秒级。它已在 6.12 合入主线。

「均衡」和「亲和」是一对反向目标

• 每核一个运行队列是前提——一个全局队列会让所有核抢同一把锁，核越多越糟。代价是队列之间会长短不齐，需要专门的负载均衡把任务搬过去。
• 但搬任务是有代价的：新核上缓存全冷（要重新预热）、TLB 也冷，跨 NUMA 节点还会让它此后一直访问远端内存（延迟高约 1.5~2 倍、带宽打折）。于是调度器要同时追求两个对立目标：让各核别闲着（均衡），又让任务别乱跑（亲和）。
• 解法是调度域（scheduling domain）分层：按硬件拓扑组织成层级，越近的层级迁移门槛越低——同物理核的两个超线程之间随便搬（共享全部缓存），同 L3 的核之间较容易搬，跨 NUMA 节点要满足高得多的不平衡阈值才搬。lscpu 和 numactl --hardware 能看到这个拓扑。

实时的定义是「有上界」，不是「快」

• 硬实时：错过截止期等于系统失效（刹车、起搏器、工业控制）。它要的是可数学证明的最坏情况——平均性能再好也不算通过。软实时：偶尔超时只是质量下降（视频掉帧、音频爆音）。
• 两个经典算法各有一句话可记：RM（速率单调）周期越短优先级越高、静态优先级，可调度性有充分条件（n 个任务时利用率上界约 n(2^(1/n)−1)，n→∞ 时趋于 69.3%）；EDF按截止期动态排，理论利用率可达 100%——代价是超载时的行为很糟（一旦开始错过，会连锁崩塌），而 RM 超载时是可预测地牺牲低优先级任务。「理论利用率更高」在实时系统里未必是优点：可预测的降级比高利用率更值钱。
• 实时性的真正敌人往往不在调度算法里，而在不可抢占的路径和优先级反转上——这也是为什么上一卡的 PREEMPT_RT 比换算法更能改善延迟。

把 count++ 拆开，竞态就没有神秘感

count++  编译出来是三条独立的指令：
   mov  eax, [count]      ← 读
   add  eax, 1            ← 改
   mov  [count], eax      ← 写

两个线程恰好这样交错（count 初值 5）：
   线程A 读到 5 ────────────────┐
                线程B 读到 5 ──┤  两边手里都是 5
   线程A 写回 6 ────────────────┤
                线程B 写回 6 ──┘  加了两次，只涨了 1

• 「丢更新」不是玄学，就是这张图：读到写之间的那个窗口里，别人基于同一个旧值也算了一遍。窗口只有两条指令宽，但一秒钟有几十亿个这样的窗口。
• 四线程各自 counter++ 一百万次，结果每一次跑都不一样（三轮分别丢了约 53%、42%、35%）——这正是竞态最难缠的地方：它不给你一个稳定的错误值去追。

三条要求，各配一个反例才记得住

三把锁的选型

两种用法性质完全不同，混着看就学不会

• 当互斥用（初值 1）：P 和 V 在同一个线程里成对出现，围住临界区。这种场合它只是个弱化版 mutex——没有持有者概念、没有死锁检查，所以能用 mutex 就别用它。
• 当同步/计数用（初值 0 或 N）：P 和 V 在不同线程里，一边等一边放。这才是信号量不可替代的地方——它自带计数，「V 了三次」等于攒下三个许可，后来的 P 能一次不漏地取走。条件变量恰恰没有这个记忆（下一卡），这是两者最实质的分工。
• 所以生产者-消费者里那两个信号量（empty/full）走的是第二种用法，而保护缓冲区的 mutex 是第一种——一个队列里同时用上了信号量的两副面孔，这也是它成为教科书首例的原因。

wait 为什么必须「原子地放锁 + 睡」

• 条件要在持锁状态下检查（否则读到的是撕碎的状态），可睡觉前又必须放锁（不放锁就没人能把条件改成真，你会睡到宇宙尽头）。「检查完 → 放锁 → 睡」如果分成三步，中间那个缝隙里别人可能刚好把条件改真并 signal 了一次，而你还没睡下——这次唤醒就永远错过了。
• pthread_cond_wait 存在的全部意义就是把「放锁」和「进入等待队列」合成一个原子动作，堵掉这条缝。所以它必须传入那把锁——不是 API 设计冗余，是语义要求。
• 标准写法固定成这个形状，一个字都别改：

  pthread_mutex_lock(&m);
  while (!条件)                  // 必须 while，不是 if
      pthread_cond_wait(&c, &m); // 原子地放锁+睡；醒来时已重新持锁
  ...在持锁状态下安全地干活...
  pthread_mutex_unlock(&m);

三个原型 → 你今天真在用的东西

• 认原型的收益是直接继承解法：认出「这是哲学家」，就知道该上全局资源排序；认出「这是生产者-消费者」，就知道该问「队列满了怎么办——阻塞、丢弃还是拒绝？」——这个问题在真实系统里比锁怎么写重要得多（无界队列是 OOM——内存耗尽、内核开始杀进程——的常见入口）。

现场确诊：死锁长什么样

• 先纠正一个高频误判：死锁的线程是 S（可中断睡眠）不是 D。它们在等 futex，属于正常的可中断等待——所以 kill 杀得掉，ps 里也看不出任何异常，只是永远不动。「卡住就去找 D 状态」会完全找错方向（D 状态指向的是存储/NFS 问题，第 03 章）。
• 零依赖的确诊命令：

  $ cat /proc/<pid>/task/*/wchan
  futex_do_wait futex_do_wait futex_do_wait   # 全部卡在 futex → 极可能是锁

  所有线程都停在 futex_do_wait、且 CPU 占用为零、堆栈几分钟不变，基本就是死锁或漏了唤醒。要看到「谁等谁」还得靠调试器：gdb -p <pid> 后 thread apply all bt（注意多数发行版 ptrace_scope=1，非父进程 attach 需要 sudo）。
• 让 glibc 帮你提前报警：把 mutex 建成 PTHREAD_MUTEX_ERRORCHECK 类型，同一线程二次上锁时 pthread_mutex_lock 直接返回 EDEADLK（35，Resource deadlock avoided）而不是挂死。默认类型什么都不查——甚至解锁一把自己没持有的 mutex 也返回 0，错误被完全吞掉。调试期把锁换成 ERRORCHECK，是性价比极高的一招。

CAS 循环：一切无锁算法的骨架

old = load(p);                    // ① 读当前值
do {
    new = f(old);                 // ② 基于它算出新值（纯计算，不改共享状态）
} while (!CAS(p, &old, new));      // ③ 只有 p 仍等于 old 才写成功；
                                  //    失败时 old 已被更新成最新值，直接重算

• 读懂这个循环就读懂了「乐观」二字：不预先排他，先假设没人跟你抢；真撞上了就重做一遍。锁是悲观的——先占住再说。
• 为什么必须是一条指令而不能拆开写：「读到 old」和「写入 new」之间只要有缝，别人就能在缝里改掉它，你的写会覆盖掉别人的更新。这就是 check-then-act 竞态，也是「原子性不可组合」的实质——两个原子操作拼起来不是原子操作。
• fetch-add 这类操作能一条指令搞定的，就别写 CAS 循环：fetch_add 无条件成功、无重试，高争用下比 CAS 循环稳得多（CAS 在争用下会退化成一群线程反复重算）。

经典重排现场：连 x86 都挡不住

初值 data = 0, flag = 0

核 A                     核 B
  data = 42;               while (flag == 0) ;
  flag = 1;                print(data);      // 可能打出 0 ！

• 三个环节都可能背锅，而且它们是独立的：编译器可以调换两条无依赖的写；CPU 的写缓冲让两条写到达全局可见的顺序与发出顺序不同；缓存一致性的传播也有延迟。单线程内硬件保证「看起来按序」，跨线程没有任何默认担保。
• 强弱之分决定 bug 在哪台机器上现形：x86-TSO 较强（只有「写后读」会乱），ARM/RISC-V 弱得多（读读、读写、写写都能乱）。所以同一份代码在 x86 上跑了三年没事，迁到 ARM 服务器或 Apple 芯片上集中爆雷——这不是新 bug，是旧 bug 终于被看见了。

RCU 三步：把「同步」换成「等旧读者走完」

写者：① 复制一份 → ② 在副本上改 → ③ 原子换指针（此刻起新读者看到新版本）
                                    → ④ 等所有可能在读旧版本的 CPU 都过一次
                                         「静止点」，然后才释放旧版本
读者：直接读指针，不加锁、不写任何共享内存 —— 开销近乎为零

• 它把代价完全挪到写端：读者一行同步代码都不用，所以读扩展性随核数近乎线性——这正是 Linux 内核在路由表、dentry 缓存这类「读几百万次才写一次」的结构上离不开它的原因。
• 第 ④ 步是全部难点：怎么知道「没人还在读旧版本」？内核的答案是宽限期（grace period）——因为读端临界区里不允许睡眠，只要每个 CPU 都发生过一次上下文切换，就证明它已经离开了任何读端临界区。这个巧妙之处也是它的限制：读端不能阻塞，所以 RCU 不是万能替代品。
• 用户态也有对应物（liburcu、epoch-based reclamation、hazard pointer），Java 的 CopyOnWriteArrayList 是同一思想的朴素版本——只是它靠 GC 免掉了第 ④ 步，这也说明有 GC 的语言写无锁结构容易得多：最难的内存回收问题被运行时接走了。

加一层间接，一次解决三个老问题

• 保护：进程 A 的页表里根本没有指向 B 内存的条目——「访问不到」比「不许访问」彻底得多。越权访问在翻译阶段就被 MMU 拦下，这就是段错误的来源。没有 MMU 的年代（实模式 DOS、无保护的单片机）任何程序都能写崩整机。
• 重定位：编译时不可能知道程序会被装到物理内存哪里。有了虚拟地址，每个程序都从固定布局开始（代码在低址、栈在高址），装哪儿由页表决定——编译器和链接器从此完全不关心物理内存。
• 共享：同一份物理页可以映射进多个进程的地址空间。这一条让共享库成为可能：一份 libc 的代码页被系统里所有进程共享，各自映射到自己方便的虚拟地址上。
• 三件事用同一个机制解决，这是「加一层间接」这个万能招式最漂亮的一次应用。代价是每次访存都要翻译——于是又逼出多级页表和 TLB（后面两卡）。

亲眼看：/proc/self/maps

$ cat /proc/self/maps          # cat 进程自己的地址空间
5601a2c00000 r-xp  /usr/bin/cat      ← text(只读+可执行)
5601a3f51000 rw-p  [heap]            ← 堆
7f42b7a00000 r-xp  .../libc.so.6     ← mmap 区：共享库
7ffce9d20000 rw-p  [stack]           ← 栈

• 每行是一个 VMA(虚拟内存区域)，权限列 r/w/x/p 直接对应页表保护位。教材上的布局图，在 Linux 里是随时可查的运行事实——顺手数数一个进程映射了多少共享库。

分段 vs 分页：一个贴合逻辑，一个贴合硬件

• 分页赢在翻译极其廉价：页大小是 2 的幂，虚拟地址天然分成「页号 + 页内偏移」，偏移直接拼过去、只需换页号。分段要做加法和越界比较，还要处理变长块的分配——硬件更喜欢固定大小的东西，这几乎是整个体系结构的偏好。
• 更关键的是分页把「外部碎片」彻底消灭了：任何一个空闲页框都能用。内部碎片有确定上界（不超过一页），外部碎片没有上界——这个差别决定了胜负。

为什么必须是树：算一遍就明白

48 位地址空间 ÷ 4KB 页 = 2³⁶ = 687 亿个页
平铺的页表：2³⁶ 项 × 8 字节 = 512 GB          ← 荒谬，页表本身装不下

x86-64 四级页表：[ 9位 | 9位 | 9位 | 9位 | 12位页内偏移 ]
                 PML4 → PDPT →  PD  →  PT  → 物理页框
每级 512 项 × 8 字节 = 4096 字节 = 恰好一个页   ← 不是巧合，是设计

• 树的全部收益是没用到的子树整棵不建。一个普通进程只用几百 MB 地址空间，页表只需几十 KB——grep VmPTE /proc/self/status 能亲眼看到这笔开销。这正是 64 位系统敢给每个进程 128 TB 虚拟空间的底气：地址空间大不要钱，只有真用到的部分才付页表钱。
• 反过来给出了它的失效条件：省不省取决于地址空间稀不稀疏。如果真把地址空间铺满，多级页表比平铺还多花中间层的开销。它之所以永远划算，是因为地址空间几乎总是极度稀疏的。
• 页表项里除了页框号，还有一排权限位：present（在不在内存）、R/W、U/S（用户态可否访问）、NX（可否执行）、dirty/accessed（写过/访问过，给置换算法当线索）。只读段、W^X、写时复制、按需调页，全是在这几个 bit 上做文章——07 章那一整章都建立在它们之上。

覆盖范围：一条能自己算的账

• TLB 覆盖范围 = 项数 × 页大小。L1 TLB 典型 64~128 项，128 × 4KB 只罩得住 512 KB；L2 TLB 一两千项也只到几 MB 量级。工作集一旦超过这个范围，就开始持续 TLB miss——每次 miss 由硬件页表行走器做几次访存补课，几十周期。
• 这条公式直接给出两个优化方向：① 换大页——2MB 页让同样的 128 项罩住 256 MB，放大 512 倍（07 章）；② 让访问集中——同样的数据量，紧凑排布比散落在大地址范围里 TLB 友好得多（这也是数组胜过指针结构的原因之一）。
• 想量出来：perf stat -e dTLB-load-misses,dTLB-loads ./prog，看的是比率不是绝对数。顺序遍历一个 1GB 数组 vs 随机遍历同一数组，两项会差出一个量级。

为什么内核要分两层

• 伙伴系统管页：按 2 的幂管理连续页块（1、2、4…页），分配时把大块对半分裂，释放时把相邻的「伙伴」合并回去。「2 的幂 + 固定配对」让合并判断变成一次位运算——伙伴的地址只差一个 bit，不需要遍历查找。这是它比通用空闲链表快的关键。
• slab / slub 管小对象：伙伴系统最小给一整页（4KB），但内核天天要分配几十字节的小结构（task_struct、dentry、inode）。slab 在页内预切好同尺寸的对象，分配就是从空闲链表取一个，还顺带缓存已构造的对象省掉重复初始化。
• 同类对象聚在同一页里带来的额外好处是缓存友好：遍历 dentry 时它们在物理上相邻。slabtop 或 /proc/slabinfo 能看到内核各类对象占了多少内存——排查「内核内存去哪了」时这是第一站。

亲眼看见「登记」与「真占」的分离

$ 一个 malloc(1GB) 但先不写的程序，读自己的 /proc/self/status：
              VmSize                VmRSS
起始           2 768 kB              1 816 kB
malloc 1GB   1 051 348 kB  ← 涨了 1GB    2 016 kB  ← 几乎没动
写满 1GB     1 051 348 kB          1 050 592 kB  ← 这才真占上
free 之后      2 768 kB  ← 大块直接还给内核（走 munmap）

• VmSize 是「我申请登记了多大的地址空间」，VmRSS 才是「真占了多少物理内存」。虚拟内存的全部生意就在这两行的差额里：地址便宜（只是页表里的一条记录），物理页贵（要真从内存里划出来），所以内核把「给你地址」和「给你内存」拆成两件事，后者拖到你真正碰它的那一刻。
• 写满 1GB 期间产生了 262 226 次 minor fault——正是 1 GB ÷ 4 KB = 262 144 页，每页第一次被碰都要陷入内核一次。这个数只取决于页大小，谁跑都一样，可以当公式记：首次触碰一片匿名内存的缺页次数 ≈ 字节数 ÷ 页大小。

同一个异常入口，四条完全不同的出路

• minor 与 major 差三个数量级，而这才是诊断的关键分界：ps -o min_flt,maj_flt 或 /usr/bin/time -v 都能看。minor 再多也只是 CPU 开销（内存分配的正常成本），major 持续升高才意味着在真读盘——那是抖动的信号。
• 一个几乎什么都不做的 /bin/true：minor fault 71 次、major 0 次。所以「缺页」绝不是异常状况——它是每个进程从出生第一条指令起就在做的事。

为什么真实系统一个都不用课本那四个

• OPT 要预知未来，只能当标尺——它的价值是给别的算法一个「离最优还差多远」的参照，不是实现候选。
• FIFO 的 Belady 异常（给更多内存反而缺页更多）暴露了一个深刻问题：置换算法未必满足「栈性质」，即 n+1 个页框持有的页集合未必包含 n 个页框时的。LRU 有栈性质所以免疫 Belady，这是它比 FIFO 强的理论根据，不只是「直觉上更合理」。
• 精确 LRU 的成本在于「每次访问都要记账」——每读一个字节都得把某个节点移到链表头，这个开销落在内存访问的关键路径上，无法接受。所以硬件只肯提供一个廉价近似：页表项里的一位 accessed 位（碰过就置 1）。Clock 算法就是围绕这一位设计的：指针转圈扫，遇到 1 就清零放过（给它第二次机会），遇到 0 就踢。「硬件只给一位，软件把它用到极致」是这一整族算法的来历。

确诊三步，别靠「感觉卡」

$ vmstat 1
 r  b   swpd   free  ...  si   so    bi    bo   in   cs  us sy id wa
 1  3  20480  15320      1024  2048  8192  1024  ...   3  5  2 90
                          ↑     ↑                            ↑
                    每秒换入 每秒换出                   等 I/O 的时间占比

• ① si/so 持续非零（不是偶尔跳一下）＝ 正在换页；② wa 高而 us 低 ＝ CPU 在等 I/O 不在算；③ b 列（阻塞进程数）持续大于 0。三条同时成立才是抖动。
• 关键区分：swpd 是存量，si/so 是速率。swap 里躺着几个 GB 冷页完全无害——它们被换出去正是内核干得对，腾出的内存拿去做了页缓存。看存量报警是最常见的误诊。
• 反过来，没配 swap 也照样能抖：内存紧张时内核会疯狂丢弃再重读文件页——包括正在执行的代码页，此时 si/so 全零而 major fault 飙升，系统卡得更突然。所以第二个诊断口径是 ps -o maj_flt 或 /proc/vmstat 里的 pgmajfault 增速。

fork 之后 RSS 说谎，Pss 才说真话

一个占 200 MB 的进程 fork 出子进程后：
          VmRSS        Pss（按共享者数量均摊）
父进程   206 492 kB    102 529 kB
子进程   205 224 kB    102 478 kB
两边 RSS 加起来 400 MB，物理内存实际只用了约 200 MB

• RSS 把共享页在每个进程上全额计一次，所以 fork 密集的服务（旧式 CGI、prefork 模型的 nginx/Apache、Python 的 multiprocessing）在 top 里看起来内存翻了几倍——把各进程 RSS 相加去做容量规划会严重高估。
• /proc/<pid>/smaps_rollup 的 Pss 把每个共享页除以共享者数量再计入，加总才接近真实物理占用。上表里 Pss 恰好是 RSS 的一半，正是「两个进程共享同一批页」的直接读数。

mmap 与 read/write：不是快慢之争，是「谁来管缓冲」之争

• 所以选择判据不是「哪个快」而是访问模式：反复随机访问一个大文件（数据库索引、mmap 的日志段）mmap 赢；一遍顺序读完（拷文件、算哈希）read 配上足够大的缓冲区就够，还不用担心地址空间。
• 延迟敏感的服务要额外小心 mmap：缺页是同步的、且发生在任意一条访存指令上——你无法用「这里会阻塞」的方式标注它，也无法给它设超时。read 至少把阻塞点收敛在一个明确的调用上。

把 free 的三列读对，90% 的「内存不足」误报就没了

$ free -h
              total    used    free   shared  buff/cache   available
Mem:           7.6Gi   2.1Gi   2.4Gi    12Mi       3.1Gi       5.2Gi
                               ↑ 别看这个           ↑ 看这个

• free 低是健康的：空闲内存不拿去缓存文件就是浪费。真正该看的是 available——「不动用 swap 就能立刻给新程序用多少」，它已经把可回收的干净页缓存算进去了。
• 回收的顺序也有讲究：干净页直接丢（内容和磁盘一致，随时可重读），脏页要先写回再丢。所以「有大量脏页时内存回收会变慢」——/proc/meminfo 的 Dirty 一行居高不下时，内存压力会连带表现成 I/O 压力。
• swappiness 调的是「回收文件页 vs 换出匿名页」的倾向，不是开关。swappiness=0 也不等于永不 swap——内存真见底时匿名页照样被换出，它只是把天平压向「先丢文件缓存」。

收益从哪来：一条能自己算的账

• TLB 的覆盖范围 = 项数 × 页大小。128 项 × 4 KB 只罩得住 512 KB；换成 2 MB 大页，同样 128 项就罩住 256 MB——整整放大 512 倍。工作集远超 TLB 覆盖范围的负载（数据库缓冲池、JVM 大堆、虚拟机内存），TLB miss 率会因此断崖式下降。
• 第二笔收益是页表变小：4 KB 页时 1 GB 内存要 262 144 个页表项，2 MB 页时只要 512 个。页表本身也要占内存、也要走 Cache，grep VmPTE /proc/self/status 能看到这笔开销。
• 反过来也给出了判据：工作集本来就小于 TLB 覆盖范围时，大页一点用都没有，只会带来下面那些代价。「开大页提速」不是普适咒语，先量 perf stat -e dTLB-load-misses 再决定。

「目录只是一张映射表」能解释一堆反直觉的现象

• 删文件看的是目录的写权限，不是文件自己的权限：在可写目录里，一个 chmod 444 的文件被 rm -f 顺利删掉；而把目录 chmod 555 后，里面权限 777 的文件报 Permission denied。因为「删除」改的是目录这张表，跟被删对象的权限位无关。
• 重命名一个文件几乎不花时间，跨文件系统「移动」却要拷贝：同一文件系统内 rename 只是改表里的一行，文件数据一个字节都不动；跨文件系统时表不通用，只能真读真写再删。这就是 mv 在同盘瞬间完成、跨盘慢如拷贝的原因。
• 文件不知道自己叫什么：名字在目录里，一个 inode 可以挂多个名字（硬链接），也可以一个名字都没有（被 rm 但仍被打开）。所以「进程能不能得到自己打开的文件的路径」这个问题，答案是「只能靠 /proc/<pid>/fd 反查，而且可能已经过期」。

软硬链接对照

• 记忆钩子：硬链接是「同一个人的另一个名字」，软链接是「写着他家地址的一张便条」。便条可以先写好、地址可以填错、人搬走了便条就失效；而另一个名字和本人共存亡。
• df -i 值得单独记一笔：inode 会先于磁盘空间用光。海量小文件的目录（邮件队列、缓存目录、构建产物）常出现「df -h 还剩一半空间，写入却报 No space left on device」——查 df -i 一眼就明白。

三种思路，对应三种「大小 vs 随机访问」的取舍

• 多级间接指针的设计意图是对小文件零开销、对大文件可扩展：前十几个直接指针让小文件一次就找到数据块，大文件才逐级动用一级/二级/三级间接块。和多级页表是完全同一种智慧——常见情况走短路径，罕见情况多付几次间接。
• 但课本讲的多级间接是 ext2/3 的实现。ext4 默认已换成 extent（用「起始块 + 连续长度」描述一整段），一个 1 GB 的连续文件可能只需要几条 extent，而多级间接要 26 万个指针。原理同源、实现已换代——读老教材时要知道这一层。

四个对象的分工，读懂它就读懂了 VFS

• superblock：一个已挂载的文件系统本身（它有多大、用哪种 FS、inode 表在哪）。inode：一个文件的元数据与数据位置（不含名字）。dentry：目录项，把「名字」绑到 inode——它是纯粹的内核缓存对象，路径查找的加速全靠它。file：一个已打开的文件，关键是它持有读写位置。
• 这个分层解释了几件事：为什么两个进程 open 同一个文件各有独立的读写位置（各有自己的 file 对象，共享同一个 inode）；为什么 fork 出的子进程和父进程共享文件位置（fd 复制时指向同一个 file 对象，所以一方 read 会推进另一方的位置——这是「父子进程写同一日志文件互相覆盖」的根因）；为什么路径越深 open 越慢（要逐级解析 dentry）。
• VFS 是面向对象思想在 C 里的手工实现：每种文件系统提供一组函数指针（相当于实现接口），VFS 通过指针多态调用。正因为契约只是「填好这组函数指针」，才会有 /proc、/sys 这种没有磁盘的文件系统，也才会有 FUSE——用户态程序也能填这组指针，于是 sshfs、s3fs 成为可能。

为什么「先写意图」就能救回来

创建一个文件要改三处（inode 位图、inode、父目录），断电落在中间就不一致

无日志：  改 inode 位图 ✔ → 断电 ✘ → 位图说这块被占了，却没人指向它（漏块）
有日志：  ① 先把「我要做这三件事」整体写进日志区并标记 commit
          ② 再去改真正的位置
          ③ 都改完了才把日志条目作废
          断电落在 ① 之前 → 什么都没发生，一致
          断电落在 ② 中间 → 重启后重放日志，把三件事补完，一致

• 关键在于日志条目本身的写入是原子的（靠校验和/commit 记录判断这条日志是否完整）。于是「多处修改」这个非原子操作，被归约成了「一次原子写 + 可重放」——WAL（预写日志）这个模式因此从文件系统一路长到数据库、消息队列、etcd 和几乎所有需要崩溃一致性的系统里。
• 代价是同一份数据可能被写两次（先日志后原地），这就是「双写放大」。三档模式正是在这笔账上讨价还价：data=journal 数据也进日志（最安全、写放大最大）、data=ordered 只有元数据进日志但保证数据先落盘（默认）、data=writeback 连顺序都不保证（最快，崩溃后文件可能含旧垃圾）。

CoW 一个决定，换来三样东西

• 快照：既然改动从不覆盖旧块，只要保留旧块的引用，就天然持有某一时刻的完整视图——快照成了「记一个根指针」，几乎零成本、瞬间完成。btrfs subvolume snapshot 或 ZFS 的 zfs snapshot 都是毫秒级返回。
• 校验和：每个块连同校验和一起写新位置，读时校验。这能抓住静默数据损坏——磁盘返回了成功、数据却是错的。传统文件系统对此完全无感（它信任磁盘），这也是为什么重要数据的长期存储偏爱 ZFS。
• 压缩/去重：块反正要写到新位置，顺手压缩或查重表并不增加额外的读改写。
• 代价同样源自同一个决定：写放大（改一个块要连带更新一路指针直到根）和物理碎片化（就地更新变成处处新分配）。所以随机写密集的数据库放在 CoW 文件系统上通常要专门调优（关掉该目录的 CoW，如 chattr +C），否则性能会随时间衰减。

「write 成功」到「数据真在盘上」之间隔着三道缓冲

你的 write()
   ↓  ① 页缓存（内存，脏页）        ← write 返回就到这儿，断电即失
   ↓  ② 磁盘自己的易失缓存           ← fsync 把①推到这儿
   ↓  ③ 盘片 / 闪存颗粒              ← 只有这里才叫持久
fsync 负责 ①→②（并请求②→③），但磁盘可能对「已落盘」撒谎

• 所以严肃场景还要往下走一步：关掉磁盘写缓存，或用带电容/超级电容保护的企业级盘（掉电后靠电容把缓存写完）。消费级 SSD 在这一点上普遍不可靠，这是「同样的数据库配置，在服务器上没事、在开发机上掉电丢数据」的原因。
• fdatasync 与 fsync 的区别值得记：前者不保证文件自身的元数据（如 mtime）落盘。对「文件大小没变、只改内容」的场景（数据库固定大小的数据文件）用 fdatasync 能省一次元数据写，这是数据库里常见的优化。

两类设备，两套语义

• 内核靠主/次设备号把 /dev 下的文件路由到驱动：主号选哪个驱动、次号选该驱动管的第几个实例。ls -l /dev/null 大小那一栏显示的 1, 3 就是这两个号，不是文件大小。
• 由此推出一个反直觉的事实：设备文件只是一块「门牌」，本身不含任何数据。rm /dev/null 删掉它，设备毫发无损；用 mknod 按同样的号码再造一块门牌照样能用。这也是容器镜像里 /dev 只需要几个 mknod 出来的节点就够的原因。

fd 视角的一次网络服务

listen_fd = socket()+bind()+listen()  # 占住端口，得到监听 fd
conn_fd = accept(listen_fd)           # 每来一个连接，发一个新 fd
read(conn_fd) / write(conn_fd)        # 与读写文件同一对 syscall
close(conn_fd)                        # 挂断 = 关文件

• fd 语义全部成立：能在 /proc/<pid>/fd 里看到、能重定向、能被子进程继承、能被 select/epoll 监视——对 shell 来说，把输出接到 socket 和接到文件是同一件事。
• 差别只在「文件」背后：数据躺在内核的接收/发送缓冲区里，对端没发数据时 read 就阻塞——下一张「五种 I/O 模型」的全部问题正源于此。
• 一个线程要同时伺候成千上万个这样的 conn_fd，就轮到本章「I/O 多路复用 epoll」卡出场——高并发服务器的整条技术线，起点就是「连接是 fd」。
• 顺带兑现另一半承诺：终端(tty)同样是文件——shell 的 fd 0/1/2 就指向终端设备，全景章主线里「字符经 tty 子系统送达 shell」，走的正是这条文件接口。

沿两个问题排开，五种模型就成了一条谱系

• 划清界线的那一刀在「谁搬数据」：epoll 只告诉你「可以读了」，真正的 read 仍是你自己同步做的——所以多路复用属于同步 I/O。只有 io_uring / Windows IOCP 这种「内核连搬运都替你做完再通知」才是真异步。把 epoll 称作「异步 I/O」是最普遍的一处术语混用。
• 信号驱动 I/O 在实践中基本没人用，原因不在机制而在信号本身太难用（不排队、handler 里什么都不能做，02 章）——它是一个「设计上说得通、工程上被淘汰」的教科书条目，知道它存在与为何被淘汰就够了。

epoll 赢在哪：把「每次传全部」变成「常驻内核」

select/poll：             epoll：
  每次调用都传入全部 fd     epoll_ctl 一次注册，fd 集合常驻内核（红黑树）
  内核线性扫一遍所有 fd     fd 就绪时由回调挂进「就绪链表」
  返回后你还要遍历找就绪的   epoll_wait 直接返回就绪的那几个
  → O(n)，n = 总 fd 数      → O(就绪数)，与总 fd 数无关

• 两处改进是独立的：① 省掉每次的用户↔内核数据拷贝（fd 集合不用反复传）；② 省掉每次的线性扫描（改成就绪时主动登记）。万级连接、少数活跃的场景两处都吃满，这是 Nginx、Redis 能用单线程扛住海量连接的机制基础。
• 反过来也给出了它的失效条件：连接数少、且几乎全部活跃时，两者都要处理所有 fd，epoll 反而多一层红黑树维护——它赢的是「万级连接、少数活跃」这个特定形状，不是所有场景。「epoll 一定快过 select」是个不成立的绝对句。

两个环形队列：把系统调用开销压到近乎为零

用户态与内核共享两块内存：
  SQ（提交队列）：你把请求写进去 ——┐
  CQ（完成队列）：内核把结果写进去 ←┘   两边都不需要拷贝

普通 epoll 路径：  每个连接每次读写至少 1 次 syscall
io_uring 路径：    攒一批请求，1 次 io_uring_enter 全部提交
                   开 SQPOLL 后内核主动来取 → 一次 syscall 都不用

• 它同时干掉了两个老瓶颈：① 系统调用次数（批量提交，甚至零 syscall）；② 数据拷贝（配合注册好的固定缓冲区与文件）。这也是为什么它在高 IOPS 下能明显超越 epoll + 非阻塞——后者的瓶颈已经不在等待上，而在每次 syscall 的固定开销上（Meltdown 之后这笔开销还变贵了，01 章）。
• 它还补齐了 epoll 最大的短板：磁盘 I/O 的真异步。普通文件加不进 epoll，而 io_uring 支持读写、fsync、openat、网络收发几乎全套——「一套接口管住所有 I/O」第一次成立。
• 「共享内存双队列」这个思想不是它发明的：NVMe 协议早就是这么和 SSD 通信的（提交队列 + 完成队列 + 一个 doorbell 寄存器）。io_uring 把同一个模式搬到了系统调用接口上——好设计会传染。

机械盘时代：算法在优化「磁头别乱跑」

• 机械盘一次寻道要几毫秒——比 CPU 慢七个数量级，所以把请求重排成磁头少跑路的顺序能带来数量级的收益。SSTF（每次选离当前磁头最近的）最省寻道但会饿死远处请求；SCAN / 电梯算法让磁头单向扫到底再回头，兼顾效率与公平——名字就说明了一切，电梯不会为了一个人来回横跳。
• 值得注意的是这些算法解决的是同一个物理约束：一个磁头、串行寻道。约束一旦消失，算法就一起失效——这是「技术方案依附于硬件假设」最干净的一个例子。

Type 1 / Type 2 的界线正在模糊

• Type 1（裸金属）：hypervisor 直接跑在硬件上，自己管调度和内存——ESXi、Xen。性能好、攻击面小，云厂商的选择。Type 2（宿主型）：跑在一个完整 OS 之上，把 VM 当普通进程管——VirtualBox、VMware Workstation，桌面上方便。
• KVM 让这个分类失了效：它是一个 Linux 内核模块，把 Linux 本身变成了 hypervisor——既是完整 OS（像 Type 2）又直接掌管硬件虚拟化扩展（像 Type 1）。于是它白拿了 Linux 全部的调度器、内存管理、驱动生态。「云上 Linux + KVM 成为事实标准」的原因就是这个「白拿」——它不需要重新实现一个操作系统该有的一切。
• 配套的 QEMU 负责设备模拟（虚拟网卡、磁盘控制器），KVM 负责 CPU 与内存虚拟化。所以 QEMU+KVM 是一对分工：说「用 QEMU 跑虚拟机」时性能天差地别，取决于有没有 KVM 加速。

三代演进，每代都在解决上一代的死结

• ① 陷入并模拟（经典理论方案）：客户机内核跑在低特权级，它执行特权指令时自然陷入，hypervisor 模拟其效果后返回。理论优雅——但在 x86 上根本走不通（见下）。
• ② 二进制翻译（VMware 的突破）：既然不能靠陷入，就在运行前扫描并改写客户机的内核代码，把那些「不老实」的指令替换成会陷入的版本。工程量巨大，但它让 x86 虚拟化第一次成为商业现实。另一条路是半虚拟化（Xen 的 PV）：干脆修改客户机内核，让它主动调用 hypervisor 而不假装自己在裸机上——快，但要改客户机，跑不了闭源系统。
• ③ 硬件辅助（Intel VT-x / AMD-V）：CPU 直接加一个新的运行模式（常被称作 Ring −1）。客户机内核可以真跑在自己的 Ring 0 上，只有指定的敏感操作才切换到 hypervisor。问题在硬件层被根治，二进制翻译和半虚拟化随之退场。

一条命令造个「容器」

$ sudo unshare --pid --fork --mount-proc bash
# ps aux      → 只看得见 2 个进程，bash 的 PID 是 1

• unshare 创建了新的 PID namespace：里面的 bash 成了「1 号进程」，宿主的进程树凭空消失。再叠加 NET/MNT namespace、cgroup 限额、pivot_root 换根，就是一个手工 Docker——容器没有魔法，只有内核特性的组合。

八种 namespace，各隔离「看见什么」

• 它们是独立的开关，可以任意组合——这正是「容器不是一个内核对象」的实质：Docker 只是替你选了一套常用组合。只隔离 NET 而共享其余的，就是网络沙箱；只隔离 MNT 的，就是 chroot 的现代版。

三类限额，各有各的语义

• CPU：两种机制别混——cpu.weight 是相对份额（只在争抢时起作用，跟 nice 同理，03 章）；cpu.max 是绝对配额（每周期最多用多少微秒，即使 CPU 空闲也不给你更多）。「配额」会造成周期性节流（throttling）：用完这一周期的额度就被强制停到下一周期，表现为延迟毛刺——查 cpu.stat 的 nr_throttled。这是 Kubernetes 上「CPU limit 设得不当反而更慢」的头号原因。
• 内存：memory.max 是硬上限，超了就在这个 cgroup 内部触发 OOM（只杀组内进程，宿主不受影响）；memory.high 是软限，超了会被主动回收与限速但不杀。「容器里进程神秘消失、宿主 dmesg 没记录」就是前者——去看 memory.events 的 oom_kill 计数。
• I/O：io.max 限带宽/IOPS，io.weight 限相对份额。注意它对缓冲写不好限（写只是变脏页，真正落盘发生在别的上下文里），所以 I/O 限流的效果常常不如预期。

对照表：差异全部源自「共不共享内核」

• 「镜像标着 ubuntu」不等于跑着 Ubuntu 内核：镜像只提供用户态文件系统（glibc、apt、bash），内核永远是宿主那一个。在任何发行版宿主上进 ubuntu 容器，uname -r 显示的都是宿主内核版本。这也解释了为什么容器跑不了需要特定内核模块的软件，以及为什么「在 Windows 上跑 Linux 容器」底下必须垫一个 Linux 虚拟机。

从「一个 root 通吃」到「按需拆分」

• Unix 三组 rwx 是起点：属主/属组/其他各三位。够简单，但表达力有限——「让 alice 和 bob 能读，别人不行」用三组权限就表达不了，这才有了 ACL（setfacl/getfacl，按用户/组单独授权）。
• setuid 解决另一个问题：普通用户需要临时做一件只有 root 能做的事（passwd 要改 /etc/shadow）。ls -l /usr/bin/passwd 权限位是 -rwsr-xr-x——那个 s 就是 setuid 位，运行时进程的有效 uid 变成文件属主（root）。
• 但 setuid root 是个粗暴的解法：程序拿到的是完整的 root，而它其实只需要一项特权。一旦它有漏洞，攻击者就借它的 root 身份提权——这是 Unix 历史上最长寿的一类提权漏洞来源。
• capabilities 就是这个问题的答案：把 root 的全能拆成几十个独立小权限。getcap /usr/bin/ping 得到 cap_net_raw=ep——ping 需要发原始网络包，于是只给它 CAP_NET_RAW 这一项，而不是整个 root。这就是最小权限原则在 OS 层面的具体形态，也是判断一个系统安全设计成熟度的直接指标：还有多少 setuid root 的二进制？

一条军备竞赛的时间线

攻击：缓冲区溢出，覆盖返回地址，跳进自己注入的 shellcode
  防：栈金丝雀（返回地址前放随机值，被覆盖即检测到）
  防：NX / DEP（数据页不可执行 → 注入的 shellcode 根本跑不起来）
攻击：ROP —— 不注入新代码，改用程序里已有的代码片段拼出逻辑
  防：ASLR（随机化布局，让攻击者不知道那些片段在哪）
攻击：靠一个信息泄露漏洞先读出某个地址，整个布局随之推算出来
  防：CFI（控制流完整性，限制间接跳转只能落在合法目标上）
  防：shadow stack（返回地址另存一份不可写的副本，返回时比对）

• 读这条线的正确方式是：每一层防御都只是提高成本，没有一层能终结攻击。所以它们的正式名字叫缓解措施（mitigation）而不是修复——漏洞还在那里，只是利用变难了。这个用词值得认真对待：把 mitigation 当 fix，会高估自己的安全水位。
• ASLR 是这里唯一「随机化」类的防御，也因此最脆弱：只要泄露一个指针，整个布局就基本失效（库内偏移是固定的）。这就是为什么现代漏洞利用几乎总是「信息泄露 + 控制流劫持」两个漏洞的组合。

四件工具，各管一个维度

• seccomp 是这几个里杠杆最大的，原因在 01 章就埋好了：系统调用是用户态影响系统的唯一合法通道。掐住这个咽喉，一个被完全攻陷的进程也做不了什么——浏览器渲染进程被攻陷后连 execve 都调不了，攻击者拿到代码执行却无法横向移动。这是「纵深防御」的精髓：假设一层会被攻破，用下一层兜底。
• 它们是正交的，所以要组合使用：只加 seccomp 但不隔离文件系统，攻击者仍能读你的密钥文件；只隔离文件系统但不限制 syscall，他仍可能通过内核漏洞提权。现代容器运行时默认同时上四件，Docker 的默认 seccomp 配置就屏蔽了几十个高危系统调用。

为什么它能改变格局：安全地把代码送进内核

• 过去想在内核里加逻辑只有一条路——写内核模块：跑在内核态、和内核共享地址空间，一个野指针就 panic 整机，还要跟着内核版本改。所以「在内核里加点观测/过滤逻辑」这件事的门槛高到几乎只有内核开发者能做。
• eBPF 换了个思路：程序先由验证器做静态检查（不能有无界循环、不能越界访存、不能读未初始化内存、栈深度有限），证明安全之后才允许加载，然后 JIT 成本机指令跑。「用验证换信任」——这是它全部革命性的来源：内核第一次可以安全地执行不受信任的代码。
• 挂载点覆盖了内核的几乎所有关键路径：函数入口/出口（kprobe/kretprobe）、tracepoint、系统调用、网络包路径（XDP 在网卡驱动层就处理包，绕过整个协议栈）、cgroup 钩子、LSM 钩子。于是同一套机制同时重写了三个领域：网络（Cilium 用它替代 kube-proxy 的 iptables）、可观测性（bpftrace 无侵入追踪任意内核函数）、运行时安全（Falco、Tetragon 检测异常 syscall 序列）。

vmstat 1：一屏看完调度、内存、I/O

$ vmstat 1
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs  us sy id wa
 1  0      0  15320   1024  89158    0    0     0     4  179  122   0  0 100  0
 ↑  ↑                                ↑    ↑                    ↑            ↑
就绪 阻塞                        每秒换入/换出              上下文切换   等 I/O

• r 是就绪队列长度（第 04 章）——持续大于核数说明 CPU 是瓶颈；si/so 持续非零才是抖动（第 07 章），swpd 有存量不算；cs 是每秒上下文切换（第 03 章），本机近乎空闲时也有一两百次；wa 高而 us 低说明在等 I/O 不在算。
• 一行数字就把四章的核心指标凑齐了，所以它是「机器慢了」时第一条该敲的命令。

htop 与 perf

• htop：进程状态 R/S/D、优先级、以及 VIRT 与 RES 两列的巨大差值——那正是第 06、07 章虚拟内存要解释的现象（申请的地址空间 vs 真占的物理内存）。
• perf stat：把「这段代码为什么慢」变成数字（IPC 每周期指令数、cache-miss、分支预测）。perf top 实时看全系统热点函数，perf record + 火焰图定位到具体调用栈（第 11 章）。WSL2 下 perf 可用，部分硬件计数器受限。

一分钟上手

$ strace -c ls >/dev/null    # 统计一次 ls 的全部系统调用
% time   calls  syscall
 21.3        9  mmap
 11.8        6  openat  ...
$ vmstat 1    # r=就绪队列长  b=阻塞数  si/so=换页  wa=等IO
$ perf top    # 实时看全系统热点函数

• 三条命令零配置、任何 Linux 都能跑。把它们对准你正在跑的任意程序，本页的进程、调度、内存、IO 就全部变成可测量的数字。

两块积木拼出来的攻击

• 积木一：推测执行的痕迹不回滚。分支预测错误时，推测执行的指令被撤销——架构状态（寄存器、内存）完美还原，但推测期间的访存已经把数据拉进了 Cache，而 Cache 状态不回滚。「撤销的执行不留痕迹」这个被默认了几十年的假设，是错的。
• 积木二：Cache 的冷热可以被测量。命中快、miss 慢，时间差足够精确地区分。于是 Cache 成了一条侧信道。
• 拼起来（Spectre v1）：反复训练分支预测器，让越界检查被预测为「通过」→ CPU 推测执行 array2[secret * 4096]，用越权读到的秘密值当下标 → 回滚后逐项测量 array2 的哪一行变热 → 秘密值就出来了。整个过程里没有任何一条指令「真正」违规执行过，架构层面无从察觉。

Linux 的四层

• ① 内核 DRM/KMS：DRM（Direct Rendering Manager）管显卡资源与显存分配，KMS（Kernel Mode Setting）负责设置分辨率/刷新率与「把哪块缓冲区显示出去」（page flip）。它是唯一能碰硬件的一层；
• ② 显示服务器 / 合成器：X server 或 Wayland compositor。管窗口的位置层级、把各窗口的缓冲区合成为一帧、分发输入事件；
• ③ 工具包：GTK / Qt。把「按钮长什么样、点了怎么办」封装好；
• ④ 应用：只往自己的缓冲区里画。

三家对照

核心差异

迁移期的现实

• XWayland：Wayland 合成器里跑一个兼容层，让 X11 应用照常工作。今天多数桌面是混合态，这也是「同一台机器上有的程序缩放正常、有的模糊」的原因（缩放策略在两条路径上不同）；
• 自动化工具受影响最大：xdotool、按键宏、屏幕录制、远程控制这类程序依赖 X11 的「谁都能看谁」，在 Wayland 下必须改用门户或合成器专有协议；
• 输入法与剪贴板是另外两处高频摩擦点，协议都重做过。

五道手（Linux）

• ① 硬件中断：键盘控制器发中断，内核驱动读取扫描码；
• ② evdev：内核把它规范化成事件（/dev/input/eventN 里的 EV_KEY、键码、按下/抬起、时间戳）；
• ③ 显示服务器 / 合成器：通过 libinput 读设备，做去抖、加速曲线、触控板手势识别，然后决定发给谁；
• ④ 工具包：把原始按键翻译成「输入了什么字符」（要经过键盘布局与输入法），再路由到具体控件；
• ⑤ 应用：收到高层事件。

「发给谁」是核心问题

• 键盘事件按焦点走：焦点窗口由合成器维护，切换时会给旧窗口发 focus-out、新窗口发 focus-in；
• 鼠标事件按位置走：命中哪个窗口就发给谁——但按下之后会隐式抓取（implicit grab），即使拖出窗口范围，后续移动与抬起仍然发给它。这就是拖拽能拖出窗口外还不断线的原因，也是 Web 前端 pointerdown + setPointerCapture 那套 API 的底层来源；
• 全局快捷键是「抓取」：某个进程向系统登记「Alt+Tab 归我」，于是它优先于焦点窗口。快捷键冲突的本质就是抓取的优先级。

为什么不从「自己写一个操作系统」开始

• 从零写 OS 的头两周会全部花在引导扇区、实模式切换、串口打印、裸机调试上——这些和进程、页表、文件系统的核心概念几乎无关，却最消耗热情。
• 而这六个项目第一天就能看到机制在跑：调度算法的周转时间、页面置换的缺页次数、目录项在磁盘镜像里的字节，全部立刻可见。
• 等这六个写完，再去啃 xv6 的 lab（下一章的路线图），你会发现自己已经认识里面的每一个数据结构——那时候要学的只剩「怎么在特权级下做同一件事」。

六个项目

怎么用这一章

• 先自己写，写不动了再看代码。每张卡的结构都是「目标 → 关键几十行 → 本机跑出来的输出 → 现在你来」，中间那段代码是骨架不是答案，故意留了扩展空间。
• 顺序建议：① 是最好的起点（一晚上能写完，成就感最大）；④⑤ 是纯计算、最轻松，适合插在中间换口味；⑥ 最难但最完整。
• 改坏它比写对它更有价值：把 ① 的 close(fd[1]) 注释掉、把 ② 的合并逻辑删掉、把 ⑥ 的直接块数从 6 改成 1，观察各自怎么坏——每一处「坏法」都对应正文里的一条设计理由。

核心就是这一段：流水线的搭建

for (int i = 0; i < nseg; i++) {                 // segs[] 是按 | 切开的各段
    int fd[2] = { -1, -1 };
    if (i < nseg - 1 && pipe(fd) < 0) break;     // 不是最后一段就先开一根管道
    if (fork() == 0) {
        if (in) { dup2(in, 0); close(in); }        // 上一段的读端接到我的标准输入
        if (fd[1] >= 0) { close(fd[0]); dup2(fd[1], 1); close(fd[1]); }
        run_seg(segs[i]);                          // 处理 < > 之后 execvp，一去不回
    }
    if (in) close(in);
    if (fd[1] >= 0) close(fd[1]);                  // 父进程必须关写端，否则下游永远读不到 EOF
    in = fd[0];                                    // 我的读端留给下一段
}
while (wait(NULL) > 0) ;                           // 等整条流水线结束

• run_seg() 里做两件事：扫一遍参数，遇到 < / > 就 open 文件再 dup2 到 0 / 1 号 fd 上，然后 execvp。exec 成功就不会返回，所以它后面那行必须是 _exit(127)——漏了这一句，一次找不到命令就会多出一个 shell 在跑。
• cd 必须写成内建命令：子进程 chdir 改的是自己的工作目录，父 shell 一点也感受不到（这条正是 00 章主线卡里那个 strace 对照实验的原理）。

用 strace 验收：机制全在这几行里

$ printf 'ls | wc -l\nexit\n' | strace -f -e trace=clone,execve,wait4,pipe2,dup2 ./minish
pipe2([3, 4], 0)                       = 0        ← 先要一根管道
clone(...)                             = 568      ← 左边的 ls
clone(...)                             = 569      ← 右边的 wc
[pid 568] dup2(4, 1)                   = 1        ← ls 的 stdout 换成管道写端
[pid 569] dup2(3, 0)                   = 0        ← wc 的 stdin 换成管道读端
[pid 567] wait4(-1, ...)                          ← 父进程蹲在这等
[pid 568] execve("/usr/bin/ls", ["ls"], ...)

• 顺带看见一个平时没注意的事实：execvp 会按 PATH 一个目录一个目录地试——本机的 strace 里先后出现了对 ~/.local/bin/ls、/usr/local/sbin/ls、/usr/local/bin/ls 的尝试，全部 ENOENT，直到 /usr/bin/ls 才成功。PATH 里排在前面的坏目录是有代价的。
• fork 在 strace 里显示为 clone：glibc 早就把 fork() 实现成了带 SIGCHLD 标志的 clone（03 章讲的「fork 和线程创建是同一个系统调用的不同参数」，这里是活证据）。

现在你来

• 加 & 后台执行：不 wait，但要处理 SIGCHLD，否则一屋子僵尸进程（ps 里的 Z 状态）。
• 加 >> 追加、2> 重定向标准错误——你会发现这只是换个 open 标志、换个 dup2 的目标 fd。
• 加 Ctrl-C 处理：为什么现在按 Ctrl-C 整个 shell 一起死？ 因为前台进程组的每个成员都收到了 SIGINT。真 shell 用 setpgid + tcsetpgrp 把子进程放进独立的进程组——这是作业控制的全部秘密。

全部机制：头部 + 空闲链表 + 首次适配

typedef struct blk { size_t size; struct blk *next; int free; } blk_t;

static void *my_malloc(size_t n) {
    n = (n + 15) & ~(size_t)15;                     // 16 字节对齐
    for (blk_t *b = head; b; b = b->next) {
        if (!b->free || b->size < n) continue;       // 首次适配：碰到第一个够大的就用
        if (b->size >= n + sizeof(blk_t) + 16) {     // 剩得下一个块就切开
            blk_t *rest = (blk_t *)((char *)(b + 1) + n);
            rest->size = b->size - n - sizeof(blk_t);
            rest->free = 1; rest->next = b->next;
            b->size = n;   b->next = rest;
        }
        b->free = 0;
        return b + 1;                                // 用户拿到的是头部之后那个地址
    }
    return NULL;
}

• 头部就藏在你拿到的指针前面——所以 free(p) 只要 ((blk_t *)p - 1) 就能找回这块的元数据。这解释了两件事：为什么 free 不用告诉它大小；为什么越界写一个字节就可能让分配器崩在下一次 malloc 里（你踩的是下一块的头部）。
• free 只做两件事：置位 free = 1，然后与右邻居合并。不合并的分配器会越用越碎。

本机跑出来的一次完整生命周期

初始        [空闲 4072]
分配 a b c  [占用 112][占用 112][占用 112][空闲 3664]
  a 与 b 相距 136 字节 = 对齐到 112 的数据 + 24 字节头部
free(b)     [占用 112][空闲 112][占用 112][空闲 3664]
  再要 64 字节 → 落回 b 原来的地址：首次适配复用了这个洞
分配 d      [占用 112][占用 64][空闲 24][占用 112][空闲 3664]
free(a)     [空闲 112][占用 64][空闲 24][占用 112][空闲 3664]
全部释放    [空闲 4072]                  ← 合并干净了，回到初始状态
留中间一块  [空闲 1200][占用 1200][空闲 1624]
  空闲总量 2824 字节，再要 2000 字节 → 失败：外部碎片

• 最后两行就是外部碎片的教科书定义：空闲字节数明明够，却没有一个连续的洞装得下。这也是为什么真分配器要分尺寸桶（glibc 的 bins）、为什么大块直接走 mmap 单独映射——绕开碎片而不是治理碎片。
• 「要 100 字节实际花掉 136」是内部碎片：对齐 12 字节 + 头部 24 字节。元数据开销在小对象上是致命的——这正是内核用 slab、语言运行时用对象池的理由（06 章内核内存分配那一卡的另一面）。

现在你来

• 把首次适配换成最佳适配（找最小的够用块），再跑一遍上面的序列——碎片形态会变，但不一定更好，这正是策略无最优解的实例。
• 加一个 my_realloc：如果右邻居空闲且够大，就地扩张不搬数据；否则新分配 + memcpy + free。写完你就明白为什么 realloc 有时候返回同一个指针。
• 把 free 里的合并循环删掉，反复 malloc/free 不同大小几千次，看空闲链表怎么烂成一地碎块。

三十行的线程库

static ucontext_t ctx[N], main_ctx;
static int done[N], cur;

static void yield_(void) {                    // 主动让出：切到下一条没结束的
    int prev = cur;
    for (int i = 1; i <= N; i++) {
        int nxt = (prev + i) % N;
        if (!done[nxt]) { cur = nxt; swapcontext(&ctx[prev], &ctx[nxt]); return; }
    }
    swapcontext(&ctx[prev], &main_ctx);        // 都结束了，回主线程
}

for (int i = 0; i < N; i++) {                 // 每条「线程」一个自己的栈
    getcontext(&ctx[i]);
    ctx[i].uc_stack.ss_sp   = malloc(65536);
    ctx[i].uc_stack.ss_size = 65536;
    ctx[i].uc_link          = &main_ctx;
    makecontext(&ctx[i], (void (*)(void))worker, 1, i);
}
swapcontext(&main_ctx, &ctx[0]);              // 开跑

• 「每条线程一个栈」这件事在这里是字面意义的：你亲手 malloc 了三块内存当栈。03 章说线程共享地址空间、各有各的栈，在这段代码里一览无余。
• 输出是干净的轮转：线程 0/1/2 各跑第 0 轮，再各跑第 1 轮……调度顺序完全由你那几行 yield_ 决定——这就是「机制与策略分离」里策略的位置。

切换到底多贵：一次把三件事同时坐实

• 二十万次往返之后，本机每次 swapcontext 约 200 ns（你的机器会不同，量级应当一致）。
• strace -c 数出来：40 万次切换恰好对应 400017 次 rt_sigprocmask——每次 swapcontext 都陷入内核一趟，只为保存/恢复信号掩码。
• 作为对照，同机器上一次最廉价的系统调用（syscall(SYS_getpid)，绕开 glibc 缓存）约 120 ns，而一轮空循环是 0.22 ns。于是账算得很清楚：切换开销的一大半就是那个没人需要的系统调用。
• 这正是 Go 运行时、Boost.Context、各种协程库不用 ucontext、自己写几十条汇编做切换的原因——纯用户态切换（只存几个被调用者保存的寄存器，一次内核都不进）可以做到几十纳秒以内，差一个数量级以上。04 章「上下文切换的真实成本」讲的是内核线程，这里量到的是它的下限。

现在你来

• 把协作式改成抢占式：setitimer 每 10 ms 发一次 SIGALRM，在信号处理函数里调 swapcontext——你会亲手造出「时间片」，也会亲手撞上「切换点可能落在任何一条指令之间」带来的所有并发问题（05 章的全部理由）。
• 给每条线程加优先级和运行计数，把 yield_ 换成 04 章的 MLFQ 规则。
• 写一个 chan_send/chan_recv：满了就让出、空了就让出——一百行之内你就有了 CSP 模型的雏形。

模拟器的全部结构

while (finished < N) {
    int i = pick(now, left, arrive);        // 策略只体现在这一个函数指针里
    if (i < 0) { now++; continue; }         // 没人就绪，CPU 空转一拍
    if (first[i] < 0) first[i] = now;       // 记下第一次被调度的时刻 = 响应
    int slice = quantum ? min(left[i], quantum) : left[i];
    now += slice;  left[i] -= slice;
    if (!left[i]) { done[i] = now; finished++; }
}

• 换算法只需换 pick：FIFO 挑到达最早的、SJF 挑剩余最短的、RR 从上次那个的下一个开始找；quantum 为 0 就是不可抢占。三十行覆盖了教科书上的四种算法。

四种策略跑同一组任务 A(0,7) B(2,4) C(4,1) D(5,4)

• 这张表把 04 章最重要的那句话变成了数字：周转和响应是一对反目标。 SJF 让平均周转最低却让 C 等到第 3 拍才第一次上 CPU；RR 让每个任务几乎立刻得到响应，代价是所有人都被切碎、整体完成得更晚。
• 没有哪一行是「最好的算法」——交互式系统买的是响应（所以桌面系统都是抢占式短时间片），批处理买的是周转。Linux 的 CFS/EEVDF 是在这两端之间找一个可调的点，不是找到了「正确答案」。
• 顺带解释了时间片长度的取舍：q 从 1 变到 2，响应没变差、周转好了一整格——因为切换次数减半。真实系统里每次切换还有实打实的开销（上一张卡量到的那 200 ns 是下限），所以时间片不能无限小。

现在你来

• 加 MLFQ：多级队列 + 用完时间片就降级 + 定期全体提升。规则不到二十行，跑完你会发现它不需要预知运行时间就逼近了 SJF 的周转——这是 04 章那一卡的核心结论，自己量出来印象完全不同。
• 给任务加 I/O：跑 2 拍就阻塞 3 拍。MLFQ 的「让出 CPU 的任务保留优先级」这条规则立刻显出价值，交互式任务不再被 CPU 密集型压死。
• 加权重（nice 值）：按权重比例分配份额，再和 04 章那张 nice 权重表对一对。

四种策略，各自只有十来行

• FIFO：一个 hand 指针轮着淘汰，谁最早进来谁走。
• LRU：每个帧记最后使用时刻，淘汰最久没用的。注意它需要在每次命中时更新时间戳——这正是真硬件做不起精确 LRU 的原因（每次访存都要写一次元数据）。
• CLOCK：LRU 的近似。命中只把访问位置 1；要淘汰时沿环扫描，遇到访问位为 1 的就清零放过（给第二次机会），遇到 0 的就淘汰。硬件只需要提供一个访问位，代价从「每次访存」降到「缺页时才扫」。
• OPT：淘汰未来最晚才用到的那个。需要预知未来，只能当标尺——但正因为是理论下界，它能告诉你现有算法还有多少改进空间。

引用串 1 2 3 4 1 2 5 1 2 3 4 5（12 次访问）的缺页次数

• FIFO 那一列是全章最反直觉的一个事实：帧数从 3 增加到 4，缺页反而从 9 涨到 10。这就是 Belady 异常——「多给内存一定更快」是错的，至少对 FIFO 是错的。CLOCK 作为 FIFO 的近亲，在这条串上同样中招。
• 为什么 LRU 不会有这个毛病：LRU 属于栈算法，n 帧时驻留的页集合永远是 n+1 帧时的子集，所以帧数只增不减地改善。这不是经验，是可以证明的性质，也是现实系统都基于 LRU 近似而不是 FIFO 的根本理由。
• 再看 LRU 在 3 帧时（10 次）居然比 FIFO（9 次）还差——没有哪个算法在所有引用串上都赢。挑一条对 LRU 最不利的串（循环访问 n+1 个页）它会全军覆没，而这种循环恰恰在真实程序里很常见（大数组反复扫描），这就是 Linux 用双链表 active/inactive 而不是纯 LRU 的原因。

现在你来

• 把引用串换成循环扫描（1 2 3 4 5 1 2 3 4 5…）跑 4 帧：LRU 缺页率接近 100%，OPT 却很低——你会亲眼看到 LRU 的病理场景。
• 实现 CLOCK-Pro / 二次机会的改进版：给每页再加一个「脏位」，优先淘汰干净页（省一次写回）。这就是真内核的做法。
• 用 /proc/self/stat 里的 minflt/majflt 观察真程序的缺页曲线，和模拟结果对照——07 章的工作集与抖动那一卡会突然变得具体。

先把布局定死（这一步就是 mkfs 做的事）

块 0    超级块    magic / 总块数 / inode 数 / 数据区起点
块 1    位图      前 16 字节 = inode 位图，后面 = 数据块位图
块 2    inode 表  16 个 inode × 32 字节 = 512，正好一块
块 3+   数据区    0 号 inode（根目录）先占走第一块

typedef struct { unsigned short type, nlink; unsigned size, direct[6]; } inode_t;
typedef struct { unsigned ino; char name[28]; } dirent_t;   // 目录 = 一张 (名字 → inode 号) 的表

• 目录不是「装文件的容器」，而是一个普通文件，内容恰好是一张表——这是 08 章最容易被跳过、也最值钱的一句话。这里它变成了字面事实：根目录就是 0 号 inode，它的数据块里躺着一排 dirent_t。
• direct[6] 意味着单文件最大 6 × 512 = 3 KB。想支持大文件就得加间接块——这个限制自己撞一次，比看十张多级索引示意图管用。

跑一遍，然后在字节里认出它们

$ ./minifs
magic=0x4D494E49 共 64 块 16 个 inode，数据区从 #3 开始
inode  名字             大小 占用的块
1      hello.txt          58 #4
2      big.bin           900 #5 #6      ← 900 字节要两个 512 块

$ hexdump -C -n 16 disk.img                       # 第 0 块：超级块
00000000  49 4e 49 4d 40 00 00 00  10 00 00 00 03 00 00 00  |INIM@...........|

$ hexdump -C -s 1536 -n 48 disk.img               # 第 3 块：根目录的数据
00000600  01 00 00 00 68 65 6c 6c  6f 2e 74 78 74 00 00 00  |....hello.txt...|
00000610  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000620  02 00 00 00 62 69 67 2e  62 69 6e 00 00 00 00 00  |....big.bin.....|

• 目录块里的字节完全对得上结构体：4 字节 inode 号 + 28 字节名字，01 00 00 00 就是 1 号 inode，后面紧跟着 ASCII 的 hello.txt。「目录项」这个词从此不再抽象。
• 超级块的 magic 我写的是 0x4D494E49（'MINI'），hexdump 里却读成 INIM——小端序在磁盘格式里的第一次照面。真实文件系统的 magic 都要显式定义字节序（ext4 的 0xEF53 存成 53 EF），跨机器搬盘才不会认不出来。
• 删文件为什么「秒删」也在这里现形：只要把位图那两位清零、目录项抹掉即可，数据块一个字节都不用动——所以数据恢复工具才有活干，所以真正要销毁数据必须覆写。

现在你来

• 实现 rm 与 ln：你会立刻明白 nlink 为什么在 inode 上而不在目录项上——硬链接就是两个目录项指向同一个 inode，只有 nlink 归零才真正释放数据块。
• 加一个一级间接块：direct[6] 之后再放一个指向「一整块指针」的块，单文件上限从 3 KB 跳到 3 KB + 128 × 512。这就是 ext2 的做法。
• 制造一次崩溃：在「分配了数据块但还没写目录项」之间退出，然后写一个 fsck 扫描位图与 inode 的一致性。你会亲手发现「两步写入不是原子的」——这正是日志（journal）存在的全部理由（08 章那一卡）。

用户态复刻不了的三样

• 特权级与保护（02 章）：你的 minish 没有能力阻止子进程读你的内存——真正的隔离来自硬件特权级和页表权限位，而设置它们的指令只有 Ring 0 能执行。这是「为什么必须有内核」的硬件答案。
• 真正的地址翻译（06/07 章）：myalloc 分的是虚拟地址，页表早就替你建好了。要亲手写页表项、处理缺页异常，必须能碰 CR3 和中断向量表。
• 中断（02 章）：所有微项目都是「被调用才执行」，而内核的另一半是「被硬件打断才执行」。定时器中断驱动抢占、设备中断驱动 I/O——没有中断，调度器根本抢不回 CPU。

下一步的两条路

• 想继续做工程：把这些骨架加厚——给 ③ 加抢占式调度和 channel、给 ⑥ 套上 FUSE 真挂载、给 ② 加线程安全后用 LD_PRELOAD 顶替 glibc。这条路的产出是能用的东西，也最像真实工作。
• 想真正进内核：直接去 xv6（下一章路线图的第 ④ 步）。它替你搭好了引导、特权级切换、中断向量这些「脚手架」，你上来就能改页表、加系统调用、写 COW fork——而这些数据结构你在本章已经全部见过一遍了，读起来完全是另一种体验。

难度递进的五步

• ① 用工具解剖真实系统：strace 一个熟悉的命令、cat /proc/self/maps、vmstat 看换页——零门槛，本页各章的「动手」线索合起来就是这一步。
• ② 写一个 shell：两百行 C 实现 fork+exec+wait、管道与重定向。做完它，进程、fd、信号从概念变成手感（13 章第 ① 个微项目给了骨架、strace 验收方法和三个扩展方向）。
• ③ 分配器、调度器、文件系统：13 章的 ②~⑥ 五个微项目正是这一档，做完再去 OSTEP projects：《操作系统导论》配套实验(实现 malloc、调度模拟器、文件系统检查器)，每章一个，坡度平缓。
• ④ xv6(MIT 6.1810)：在一个几千行、真能读完的教学内核上做 lab——加系统调用、实现 COW fork、写页表、改调度器。这是从「用 OS」跨到「改 OS」的标准路径。
• ⑤ 进阶选修：给 Linux 写一个字符设备驱动模块；用 bpftrace 追一次真实性能问题；读一遍 kernel/sched/ 下的 EEVDF 源码。

书与资料(按阶段)

• 入门首选：OSTEP《操作系统导论》——免费在线，以「虚拟化/并发/持久化」三条主线组织，本页结构与之深度呼应。
• 打通上下：CSAPP(深入理解计算机系统)——程序员视角看 OS 与硬件的接缝(配合组成原理页)。
• 深入内核：《深入 Linux 内核架构》或 Robert Love《Linux 内核设计与实现》；系统编程配 The Linux Programming Interface。
• 保持更新：LWN.net(内核演进的第一手报道)、Brendan Gregg 的博客与《性能之巅》(观测方法论)。