第 9 章 中断、系统调用与块层

内核与外部世界只有两个接口：硬件从外面打断它（中断），或它主动出去取活干（系统调用）。本章把这两条边界和其后的 I/O 栈一次拆到底。

学习目标

读完本章，你应当能够：

1. 论证「轮询 vs 中断」的取舍判据，并解释 NAPI 与 NVMe 的 io_poll 为什么会主动退回轮询。
2. 区分硬中断、软中断、tasklet、工作队列、线程化中断的运行上下文与「能否睡眠」判据，说出 ksoftirqd 存在的理由与软中断风暴的三种表现。
3. 画出 x86-64 上一次系统调用从用户态准备寄存器到 sysretq 返回的路径，逐项拆解开销来源与量级。
4. 解释 vDSO 能让 clock_gettime 不进内核、却不能让 getpid 也不进内核的原因。
5. 说明信号的产生/阻塞/未决三态与 SIGCHLD 丢失的根因，写出一个可重入安全的信号处理函数。
6. 画出从 write 到设备队列的块层 I/O 栈，按设备类型选择 I/O 调度器，并说清 fsync 到底保证了什么。

前置知识检查

9.1 中断存在的理由：从轮询到事件驱动

不用中断，CPU 想知道设备有没有新数据，只能反复读设备状态寄存器——这就是轮询（polling）。设备完成间隔为 T、轮询周期为 p 时，平均发现延迟是 p/2，CPU 花在无效询问上的比例与 p/T 同阶：压延迟就得减小 p，而减小 p 直接吃 CPU，「低延迟」与「不浪费 CPU」在轮询下不可兼得。中断把「谁决定何时处理」从 CPU 转交给设备，但轮询并未消失，因为它有两个中断给不了的性质：

判据不是「谁先进」，而是 中断固定开销 × 事件频率 与 轮询单次成本 × 询问次数 谁更小。Linux 网络栈的 NAPI 就是混合方案：第一个报文触发硬中断，随后关闭该队列中断并在软中断上下文按预算（net.core.netdev_budget，默认 300）轮询收包环，把「每包一次中断」降为「每批一次中断」；NVMe 在队列深度大、IOPS 高的场景也允许纯轮询（io_poll），代价是必须独占一个 CPU 不让出去。

9.2 上半部与下半部：中断处理为什么必须被切开

硬中断（hardware interrupt, hardirq）的处理函数运行在一个没有对应 task_struct 的特殊上下文里。这带来两条硬约束：处理期间该 CPU 上（视屏蔽位）该中断线被屏蔽，其他设备事件被推迟；且它不能睡眠（理由见 9.3）。于是处理函数一旦变长，全局响应性一起变差。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

  一次网络收包在时间轴上的拆解（上半部只做"登记"，下半部做"干活"）
  硬中断上下文（不可睡眠、不可被同线中断抢占）
    irq_handler(): 读状态寄存器 → 确认是自己的中断 →
      acknowledge（清中断标志，否则不再触发）→
      raise_softirq(NET_RX_SOFTIRQ) → iretq 返回      [耗时几百纳秒 ~ 2 μs]
        │ 中断返回路径
        ▼
  irq_exit() 检查 per-CPU 的 __softirq_pending 位图
    ├─ 有 pending → invoke_softirq() 直接执行（仍算软中断上下文，不可睡眠）
    └─ 轮次/时长超限，或已有软中断在跑 → wakeup_softirqd() 转 ksoftirqd/N

「上半部必须短」不是风格要求，而是三条物理约束的推论：中断处理期间同线中断被屏蔽，处理越久越容易丢后续事件；上下文本身把能做的事限死；硬中断会打断任意代码包括持锁临界区，处理越久越容易与被打断者形成互等路径，放大锁竞争与抖动。

下半部（bottom half）不是一样东西，而是一族机制，区别只在运行上下文与由此决定的能否睡眠：

判据只有一条：这段代码会不会睡眠。会睡眠（等锁、等 I/O、可能触发回收的分配）就必须进工作队列或线程化中断；不会睡眠但很重（遍历收包环、遍历定时器）用软中断；不会睡眠且极短（读状态位、应答）留在上半部。

9.2.1 ksoftirqd 与软中断风暴

软中断的调度有两个相互矛盾的诉求：延迟低（有 pending 就立刻做）与饿不死别人（不能无限做）。内核先直接做一轮：__do_softirq() 最多执行 MAX_SOFTIRQ_RESTART（10）轮、总时长受 MAX_SOFTIRQ_TIME（约 2 ms）限制；预算用尽后若仍有 pending，就唤醒 per-CPU 的 ksoftirqd/N，把剩余工作交回可被调度器管理的进程上下文。因此 ksoftirqd 给出的保证是：软中断不会在中断返回路径上无限占用 CPU；它自己也是普通调度类任务，于是「软中断很多」从「卡死中断返回」变成「多一个忙线程」。软中断风暴的三种表现与处置：

处置按「减压 > 分流 > 限流」排序：先减少事件本身（中断合并、GRO/TSO、批处理预算），再把软中断按 RSS 多队列分摊到多核（9.4 节），最后才考虑调参数。单纯调大 net.core.netdev_budget 只是把工作从软中断搬到应用，不解决根因。

9.3 中断上下文为什么不能睡眠

这条结论是所有中断类追问的终点，必须能推出。内核里「睡眠」的完整含义是四件事：把当前任务从运行队列摘掉置为睡眠态；注册一个等待项记录「谁在什么条件下唤醒我」；调用调度器切换（保存现场、切地址空间、可能切栈）；将来由另一个上下文通过等待项重新入队。硬中断与软中断上下文缺的是第 1 步的主体和第 4 步的对象：中断处理函数运行在当前任务的内核栈之上，没有自己的任务实体，也不是调度器队列成员。若它调用了会睡眠的函数，调度器切走之后栈上那份中断帧就悬在那里，且没有任何数据结构记录「这个中断没处理完」，也就没有谁有能力唤醒它。结果不是报错，而是该 CPU 上这个上下文永久消失（schedule while atomic 之类告警正是内核在尽力拦截）。由此推出三个禁区与替代方案：

判定接口是 in_interrupt()，等价于 in_irq() || in_softirq() || in_nmi()。要留意 in_softirq() 的含义是「软中断上下文或已禁用下半部」，所以把代码包在 local_bh_disable() 里也会让它为真——这解释了一些看似正常的路径为何命中「不能睡眠」的断言。与之互为镜像的是 in_atomic()（在中断里、或持自旋锁、或已关抢占）。

9.4 多核下的中断：屏蔽、亲和性与多队列

与性能最相关的是路由：中断落在哪个核上，决定了后续处理是否要跨核搬运数据。若中断处理的核与消费数据的线程不是同一个核，数据会在核间来回搬，cache line 反复弹跳（见第 1 章 1.5 节的缓存一致性与 NUMA 代价），直接变成吞吐损失。观测面是 /proc/interrupts（每行一个中断、每列一个 CPU 的累计计数）、/proc/irq/N/smp_affinity（十六进制位掩码，如 echo 0c > /proc/irq/128/smp_affinity 把 128 号中断限到 CPU 2、3）与 smp_affinity_list（如 2-3），irqbalance 守护进程则按负载自动调整；/proc/softirqs 给出软中断的 per-CPU 计数，要与中断分布对照看是否均匀，而不是只看总量。

接收端缩放（receive side scaling, RSS）解决的是「一块网卡只发一个中断、单核扛不住线速」的问题：网卡按包头五元组算哈希，把结果映射到 N 个接收队列之一，每个队列绑定一个独立中断向量，再由 smp_affinity 或驱动配置把这些中断分摊到不同 CPU（ethtool -l eth0 看通道数，ethtool -L eth0 combined 8 调整，ethtool -n eth0 rx-flow-hash tcp4 看哈希字段）。它的两个边界必须说清：第一，同一条流永远落在同一个队列（哈希输入是流标识），所以单连接吞吐上限仍是单核处理能力，救单流要靠 RPS（软件层把收包分散到其他核，代价是跨核传递）或多连接分片；第二，哈希可被构造，攻击者能造出大量哈希相同的流把所有流量压到一个队列，这也是随机种子（ethtool -X ... hkey）与 RFS 存在的理由。

9.5 系统调用的完整路径

系统调用是主动的受控入口。x86-64 上这条路径由硬件约定与内核入口代码共同实现，第一层是寄存器约定：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

  x86-64 上一次 syscall 的完整路径（⇒ 控制流，→ 数据/状态）
  用户态                             内核态
  ─────────────────────            ─────────────────────────────────────────
  ① libc 包装 write():              ② syscall 指令 ⇒ 硬件动作（微码不查 IDT）:
     mov eax,1; mov edi,fd;            CS/SS 换内核选择子、CPL 置 0
     mov rsi,buf; mov edx,len          rcx ← 返回地址, r11 ← rflags, rip ← MSR_LSTAR
                                    ③ entry_SYSCALL_64（汇编）: swapgs 切内核 per-CPU 区,
                                       push 寄存器构建 pt_regs, 校验返回点是否合法
                                    ④ do_syscall_64(regs, nr): nr = regs->orig_ax
                                       if (nr >= NR_syscalls) return -ENOSYS
                                       f = sys_call_table[nr]     ← 数组索引 O(1)
                                    ⑤ 真实实现（如 ksys_write）: 校验 fd 与用户指针范围,
                                       copy_from_user（可能缺页、可睡眠）→ 进 VFS 与块层
                                    ⑥ 返回前 ret 或 (long)-errno；work_pending? 处理信号/重调度
  ⑧ libc 检查 rax<0 → errno=-rax;   ⑦ sysretq / iretq: rcx、r11 恢复 rip 与 rflags，
     return -1；否则直接返回 rax        swapgs 切回用户态

路径上有四个必须能指出的细节。其一，syscall 不查 IDT：与 int 0x80 相比，它专为「跳到固定内核入口」设计，省掉了查中断描述符表与完整特权级栈切换的流程，这是 x86-64 快于 32 位路径的硬件原因。其二，入口要做的工作远不止保存寄存器：还要处理用户/内核 GS 基址切换（SWAPGS）、校验返回地址、应用 Spectre 类缓解措施（entry trampoline、返回 thunk、必要的 LFENCE 与 IBRS 系列）并确定内核栈位置，这些附加工作是「同一台机器换个内核版本，系统调用就慢了」的直接原因，也是实测区间很宽的主因。其三，参数校验与拷贝是可变成本：copy_from_user/copy_to_user 要检查用户指针合法性（不能指向内核地址），且首次触碰用户页可能触发缺页而睡眠（见第 8 章 8.3 节），所以成本是「固定切换成本 + 与数据量相关的拷贝成本 + 概率性的缺页成本」。其四，错误约定在内核边界是负值：内核函数返回 -EINVAL 这类负错误码，test rax, rax; js error 是内核判断失败的标准写法，翻译成 errno 是 libc 的职责，被追问「内核里怎么判错」时答 errno 是错的。

9.6 系统调用的开销构成与省掉它的手段

结论是一次系统调用约 100 ns ~ 1 μs：比一次函数调用（约 1 ns）贵约 100_{1000 倍，但比一次完整的进程上下文切换（约 1}5 μs）便宜，因为它没有切换任务，只切了特权级与地址空间视角。省掉它的手段分两类：

9.6.1 vDSO 与 vSyscall

虚拟动态共享对象（virtual dynamic shared object, vDSO）是一段由内核映射进每个进程地址空间的小型 ELF 映像（地址通过辅助向量 AT_SYSINFO_EHDR 告知用户态）。它里面的代码是内核用一份「同时可在用户态与内核态运行」的实现编译出的只读代码与数据页，因此可以读内核维护的时间数据而不发生特权级切换。为什么时间可以：墙上时间与单调时间有一个内核持续更新的结构（vvar 页），用户态只需读两个字段再做定点乘加即可换算，无需求助内核逻辑。这就是 gettimeofday 不陷入内核的原因——走 vDSO 的 clock_gettime(CLOCK_MONOTONIC) 在几十纳秒量级，对应系统调用在数百纳秒量级；每请求取两次时间的服务因此能省下可观 CPU。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

/* 验证 vDSO：在 strace 下运行，若时间调用不出现 syscall 行即走了 vDSO 快路径 */
#define _GNU_SOURCE
#include <time.h>
int main(void) {
    struct timespec ts;
    /* 用 MONOTONIC 而非 REALTIME：前者不受 NTP 阶跃影响，算间隔不会被回拨搞成负数；
       返回值检查也不能省——seccomp 过滤或非主流架构下会退回真正的系统调用 */
    clock_gettime(CLOCK_MONOTONIC, &ts);
    return ts.tv_sec < 0 ? 1 : 0;
}

两个时钟的选择是并发场景的常见陷阱：CLOCK_MONOTONIC 从某个不可指定的起点单调递增，不受系统时间被调整影响，是测间隔、实现超时、算 P99 的正确选择；CLOCK_REALTIME 是墙上时间，可能被 NTP 逐步校正或被 settimeofday 阶跃跳变，用它算两次之差可能得到负数。补充选项是 CLOCK_MONOTONIC_COARSE：直接读内核每个 tick（jiffies，典型 1~4 ms）更新的粗粒度值，精度换速度，适合「只要大致耗时」的高频统计。vDSO 的边界也是这道题的追问方向：

9.7 中断与系统调用的开销差异

两者都跨越特权边界、都要保存现场，但成本结构不同，差异来自可预期性：

一句话总结根因：系统调用的入口是「已知的、自愿的、可优化的」，中断的入口是「未知的、强制的、必须完整兜住的」。只保留现场这一项，中断就比系统调用贵得多。

9.8 信号：软件层的异步通知

信号（signal）是内核向进程投递的异步通知，与中断的类比是「硬件打断 CPU、信号打断进程」。但类比到此为止：

9.8.1 产生、阻塞、未决

三个概念互相正交，混为一谈是最常见的答错点：产生（generate）指 kill/raise 或内核事件（子进程退出、写管道失败、定时器到期）把信号加入未决集；阻塞（block）指 sigprocmask 设置的屏蔽集决定「暂时不接收」哪些信号，阻塞不丢弃信号；未决（pending）指信号已产生但尚未投递（deliver）。三者的关系只有四种组合：

1
2
3
4
5
6
7
8

  信号从产生到投递的四条路径（判定"会不会丢"必须同时看阻塞集与未决集）

  kill(pid, SIGUSR1)
    ├─ 在阻塞集中 ──▶ 置未决位（不投递、不丢失）→ 解除阻塞时投递
    ├─ 不在阻塞集、未决位已置位、且是标准信号 ──▶ 合并：仍只占一个未决位（不计数！）
    ├─ 不在阻塞集、未决位为空 ──▶ 置位并立即投递：内核改用户栈与 rip，返回用户态时执行 handler
    └─ handler 为 SIG_IGN 或默认动作是忽略 ──▶ 直接丢弃，不占未决位
  注意：阻塞 ≠ 忽略。SIG_IGN 是"收到了但不要"，阻塞是"先收着，等会儿再给"。

未决集的合并语义：未决集中已有某个标准信号时，再来一个同种信号只会置同一个未决位，所以「产生过 N 次」无法从状态还原。实时信号（SIGRTMIN~SIGRTMAX）按值排队，因此是可靠信号——「不可靠信号 vs 可靠信号」的准确含义就是不可靠 = 不排队、会合并。

9.8.2 SIGCHLD 为什么会丢

SIGCHLD 是标准信号，因此多个子进程同时退出只留下一个未决的 SIGCHLD。这与「每个子进程退出发一次通知」是完全不同的事实，后果是两个常见 bug：以为 SIGCHLD 计数等于退出的子进程数（计数永远偏小，僵尸堆积）；在处理函数里只 wait() 一次（剩下的僵尸要等下一个子进程退出才可能被回收）。正确写法是循环回收，并保持可重入安全：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

static volatile sig_atomic_t reaped = 0;  /* sig_atomic_t 保证信号上下文中的读写在指令层面不撕裂 */

static void on_sigchld(int signo) {
    int saved = errno, status;            /* handler 会打断任意代码，必须自己保存/恢复 errno */
    /* 必须用 WNOHANG 循环而不是 wait：SIGCHLD 会被合并，一次通知可能对应多个已退出的子进程 */
    while (waitpid(-1, &status, WNOHANG) > 0) {
        reaped++;                         /* 只做自增，不做任何可能加锁或分配内存的操作 */
    }
    errno = saved;
}
/* 安装必须用 sigaction：signal 语义随实现而异，且只有 sigaction 能显式控制屏蔽集与标志位。
   SA_RESTART 让被打断的慢系统调用自动重启，代价是"用信号打断阻塞调用"这一惯用法失效 */
struct sigaction sa = { .sa_handler = on_sigchld, .sa_flags = SA_RESTART | SA_NOCLDSTOP };
sigemptyset(&sa.sa_mask); sigaction(SIGCHLD, &sa, NULL);

9.8.3 可重入约束：为什么只能调异步信号安全函数

处理函数只能调用异步信号安全（async-signal-safe）的函数，这是 POSIX 的明确规定（signal-safety(7) 给出安全函数清单）。原因不是风格而是机制：处理函数可以打断任何代码，包括正在修改 malloc 空闲链表、正持 stdio 内部锁、正在更新 locale 全局状态的代码。故障形态只有三类：被中断的代码正持 malloc/stdio 的锁而处理函数再进同一把锁，导致同一线程自锁（非递归锁）而永久挂起；被中断的代码只完成链表的「摘下」还没「接上」，处理函数写同一结构导致链表断裂或双重释放；处理函数内的失败调用覆盖 errno，返回后上层用错误码走错分支。安全的工程手段有两种：只设置 volatile sig_atomic_t 标志或自增计数，由主循环检查；或在处理函数里往一个非阻塞管道的写端写一个字节，把通知转成 I/O 事件交给主循环（self-pipe trick）。需要复杂回收时，现代做法是用 signalfd 把信号变成可读文件描述符交给 epoll（见第 7 章 7.5 节）。

9.9 块层与 I/O 栈

从 write 返回到数据真正落在介质上，中间隔着一串职责明确的层。这张图是本章的第二个必画图：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

  一次 buffered write 的完整下沉路径（箭头方向即数据与控制流方向）
  用户态 write(fd, buf, len) → 系统调用入口（见 9.5 节）
    ▼
  VFS：file->f_op->write_iter；判断是否 O_DIRECT：是 → direct_IO，否 → buffered 路径
    ▼
  page cache（第 7 章 7.6 节）
      copy_from_user 把用户数据拷进 page cache 的页（第 1 次搬运）
      folio_mark_dirty 把页标脏并挂到该 inode 的脏页结构上
      ★ 此刻 write 就可以返回了 —— 数据在内存里，不在盘上
      回写（writeback）异步进行，触发条件四类：① 脏页占比 > dirty_background_ratio
        （默认 10%）→ 唤醒 flusher 后台写；② 占比 > dirty_ratio（默认 20%）→ 前台进程
        自己写，write 被拖慢；③ dirty_expire_centisecs（默认 3000 = 30 s）到期；
        ④ fsync / sync / sync_file_range 显式要求
    ▼
  文件系统（ext4/xfs）：分配或查找 extent，生成 bio（页、偏移、长度、方向）
    ▼
  块层四件事：1. 合并：相邻 bio 合进已有请求，减少下发请求数；2. 排队：per-CPU 软件队列
              → 映射到硬件队列（blk-mq）；3. 调度：none / mq-deadline / kyber / bfq 决定顺序
              与并发度；4. 拆分：超过设备最大扇区数的请求被拆成多个
    ▼
  设备驱动（nvme / sd / virtio_blk）：bio → 设备专有命令，建 DMA 映射，写门铃通知设备
    ▼
  设备队列（深度受 NCQ/TCQ 与设备能力限制）→ 设备内部重排并行执行 → 介质
    ▼  完成：设备发中断（MSI-X）→ 上半部快速应答 → BLOCK 软中断里跑 bio 完成回调 end_io
        → 解锁页、更新统计、唤醒等待该页的进程 → 等待者（可能一直在 sync 路径处于 D 状态）返回用户态

从这张图能推出三个常被追问的结论：write 成功不等于数据落地（buffered 路径只保证进了 page cache）；一次 buffered I/O 至少两次数据搬运（用户缓冲 → page cache 是 copy_from_user，page cache → 设备是 DMA），这是零拷贝要省的对象（见第 7 章 7.6 节）；大量 D 状态出现的位置就在这条链上（等 page lock、等 bio 完成），所以平均负载高而 CPU 低时要看 vmstat 的 b 列（见第 11 章 11.1 节）。

9.9.1 I/O 调度器：四种算法的适用面

多队列块层（blk-mq）里调度决策发生在软件队列层，硬件队列只负责执行。四种调度器的取舍由设备随机访问代价与队列深度决定：

选择判据可以压缩成一句：设备自己能重排（深队列 + 内部调度）就选 none；需要延迟上界选 mq-deadline 或 kyber；需要带宽公平选 bfq。 查看与切换只需读写这几个 sysfs 文件：

1
2

cat /sys/block/nvme0n1/queue/scheduler; echo mq-deadline > /sys/block/sda/queue/scheduler  # 方括号内为当前生效项
cat /sys/block/nvme0n1/queue/nr_requests; cat /sys/block/sda/device/queue_depth  # 队列深度决定在途请求数

队列深度必须给算例。设单次随机读耗时 L = 100 μs（SSD），队列深度为 Q，则理论 IOPS = Q / L：Q = 1 时 IOPS = 1 / 100 μs = 10⁴，即 10 K IOPS，这就是「同步逐条下发」的天花板；Q = 32 时 IOPS = 32 / 100 μs = 3.2 × 10⁵，即 320 K IOPS。同一设备、同样单次延迟，只因在途请求数不同就差 32 倍——这是「应用必须并发下发 I/O」的量化理由，也是 fio 报 IOPS 必须同时报 iodepth 的原因。机械盘相反：L 由寻道主导（约 5~10 ms），重排能减少寻道次数，所以深队列 + 调度器重排才让它接近顺序访问，NCQ（SATA，队列深度 32）与 TCQ（并行 SCSI，深度更大）提供的就是这个能力。

9.9.2 buffered I/O 与 direct I/O

两条路径的差异不只是「有没有 page cache」，而是谁负责缓存、谁负责对齐、谁负责同步：

O_DIRECT 的两个坑必须说出来：其一，写路径上内核可能因为正在回写该文件重叠区域而阻塞新请求，造成延迟尖峰（顺序一致性要求）；其二，对齐要求让应用必须自己处理「不足一个块的尾巴」，通常做法是按块读写、尾部单独处理。因此「无脑上 O_DIRECT 更快」是错的：它只在「应用自己有缓存」或「数据确定不会被复用」时才划算。

9.9.3 fsync 到底保证了什么

fsync(fd) 的语义是：把该文件所有已修改数据与足够的元数据（使得数据能被读回来所需的元数据，如大小、块映射）下推到持久介质，并等待设备报告完成。三个层次必须分清：

必须同时说清 fsync 的三个边界：它管不到硬件写缓存——若设备易失性写缓存处于「已确认未落介质」的模式，fsync 返回成功仍可能掉电丢数据，要真正保证需开启写缓存刷写（FUA / 写屏障），代价是吞吐下降，这是「数据安全」与「IOPS」之间无法回避的取舍；它不保证父目录——新建文件后必须对目录也 fsync，否则掉电后可能「文件内容在，但名字不在」；它是同步点，会串行化——高并发下逐笔 fsync 会让吞吐被设备延迟锁死（IOPS = 1 / L，对 L = 100 μs 的设备约 10 K 次/秒），工程解法是组提交（group commit）：把多个事务的日志合并成一次 fsync，用「一批的等待」换「一次设备往返」。这正是第 21 章 21.3 节 MySQL redo log 组提交要解决的问题，也是 innodb_flush_log_at_trx_commit 三档（1 = 每次提交都刷、2 = 写 OS 缓存每秒刷、0 = 交给后台线程）背后「不丢」与「不卡」的取舍。

本章小结

自测题

Q1（判断）「中断一定比轮询高效，因为轮询要一直占用 CPU。」这句话对吗？请给出判据并说明 NAPI 属于哪一类。

Q2（推导）为什么软中断上下文不能睡眠？请从「睡眠」在内核中的完整含义出发推导，并说明 in_interrupt() 与 in_softirq() 的判定范围差异。

Q3（推导）为什么 gettimeofday 可以不进内核，而 getpid 不行？如果进程通过 seccomp 装了严格的系统调用过滤器，vDSO 会带来什么麻烦？

Q4（设计）一个服务在低峰期正常，高峰期 top 显示 si 很高、ksoftirqd/* 占满若干核、接口 P99 恶化。请给出排查顺序与处置方案，并说明为什么先做某一步。

Q5（计算 + 辨析）某 SSD 单次随机读延迟 L = 100 μs，应用以同步方式逐条下发。理论 IOPS 上限是多少？并发提升到 32 后是多少？再回答：fsync 返回成功后，数据是否一定不会因掉电丢失？

面试高频问题与陷阱

延伸阅读

• man 2 syscall、man 2 syscalls、man 7 signal、man 7 signal-safety、man 2 fsync、man 2 open（O_DIRECT 的语义与对齐要求）、man 5 proc（/proc/interrupts、/proc/softirqs、/proc/irq/*/smp_affinity）。
• Linux 内核源码文档：Documentation/core-api/genericirq.rst（中断子系统与线程化中断）、Documentation/block/（bfq-iosched.rst、kyber-iosched.rst）、arch/x86/entry/entry_64.S（entry_SYSCALL_64 与 sysretq）、arch/x86/entry/syscalls/syscall_64.tbl（系统调用号唯一权威表）。
• Intel 64 and IA-32 Architectures Software Developer’s Manual, Volume 2（SYSCALL/SYSRET/SWAPGS 的硬件语义）、Volume 3（APIC 与 MSI-X 中断投递）；NVM Express Base Specification（提交/完成队列、门铃机制与队列深度定义）；fio 官方文档（iodepth 与随机/顺序口径）；Bryant & O’Hallaron, Computer Systems: A Programmer’s Perspective（第 3 版第 8 章「Exceptional Control Flow」）；Arpaci-Dusseau, Operating Systems: Three Easy Pieces（「Dialogs on Virtualization」「Hard Disk Drives」「Redundant Arrays of Inexpensive Disks」三节）。