POSIX 内存管理与 mmap

• 理解 read/write 的用户态复制
• 理解数据复制次数差异
• 理解页缓存共享

mmap 将文件页直接映射到进程地址空间，通过缺页机制按需加载页，访问时由 CPU 直接操作页缓存中的页，无需在用户态与内核态之间复制数据（仅一次页表建立，缺页时从磁盘读入页缓存）。read/write 每次调用都需将数据从内核页缓存复制到用户缓冲区（read）或从用户缓冲区复制到内核（write），即存在一次用户态<->内核态的数据拷贝。因此 mmap 在"读改写"场景减少一次复制，且页缓存可被多个进程共享（MAP_SHARED），减少重复读盘。差异来源：复制次数（mmap 零拷贝 vs read/write 一次拷贝）与页缓存共享。mmap 的缺页开销（page fault）与地址空间管理是其代价，随机小读写时 read/write 可能更优。

核心差异是"是否经过用户态缓冲区复制"。mmap 直接映射页缓存，减少拷贝并支持共享；read/write 必须复制。但 mmap 有缺页与 TLB 开销，需按访问模式权衡。

• 理解 mprotect 的权限控制
• 理解 RLIMIT_MEMLOCK
• 理解权限与内存锁定

mprotect 修改内存区域的访问权限（PROT_READ/WRITE/EXEC/NONE），用于保护内存（如只读数据段、守页检测越界）。mlock 将内存页锁定在物理内存中，防止被换出到磁盘，用于对延迟敏感或需常驻内存的数据（如密钥、实时数据）与实时性要求高的场景（避免换页抖动）。RLIMIT_MEMLOCK（getrlimit/setrlimit）限制进程可锁定的内存总量，超出时 mlock 返回 ENOMEM。锁定内存过多会减少可用物理内存，因此系统设置上限。非特权用户受 RLIMIT_MEMLOCK 限制，需权限或调大 rlimit。mlockall 可锁定整个地址空间。

mprotect 控权限、mlock 控常驻。两者都是内存管理操作。RLIMIT_MEMLOCK 是资源上限，防止锁定过多物理内存。理解限制有助于避免 mlock 失败。

• 理解惊群（thundering herd）
• 理解 EPOLLEXCLUSIVE 语义
• 理解与 accept 的结合

多个 epoll 实例或线程同时等待同一 listen fd（如 SO_REUSEPORT 配合多 epoll），新连接到达时传统 epoll 会唤醒所有等待的 epoll_wait，造成惊群——多个线程被唤醒但只有一个能 accept 成功，其余空转。EPOLLEXCLUSIVE 标志（加到 EPOLL_CTL_ADD 的 events 中）使内核只唤醒一个等待者（等待的 epoll 实例之一），避免惊群。它通过内核层面的唤醒仲裁，只唤醒队列中的一个 waiter。但 EPOLLEXCLUSIVE 与 EPOLLONESHOT 不能同时使用（互斥），且用于多线程时需配合 accept 的原子性（如 SO_REUSEPORT 或单线程 accept 分发）。EPOLLEXCLUSIVE 只对监听套接字有效。

惊群是"多个等待者被同时唤醒但只有一个能处理"。EPOLLEXCLUSIVE 让内核只唤醒一个，减少无效唤醒。它限用于 listen fd，且不能与 EPOLLONESHOT 同用。

• 理解 IORING_OP_SPLICE
• 理解文件类型与偏移限制
• 理解 splice 的语义

IORING_OP_SPLICE 是 io_uring 对 splice 系统调用的封装，用于在文件与管道之间零拷贝传输数据。它要求一端为管道，因为 splice 的实现依赖管道页缓存（pipe_buffer）的借用，数据可在文件页缓存与管道之间通过页引用传递，避免复制。文件类型限制：普通文件与管道可用，但某些文件类型（如目录、设备特殊文件）或需要即时移动的场景受限；splice 对源要求可读到页缓存，目标可写。偏移限制：对普通文件可用 off 参数指定偏移；对非 seekable 或 pipe 则自动使用当前偏移，pipe 无法随机偏移。splice 设计上不用作通用文件到文件复制，主要面向管道与页缓存。

splice 零拷贝依赖"页引用借用"，管道是其中一端的前提。文件类型与偏移受限因其依赖页缓存与顺序语义。理解限制可避免误用 splice。

• 理解抽象解释
• 理解寄存器/栈状态追踪
• 理解安全终止与内存安全

BPF 验证器在加载时对程序做静态分析（抽象解释），模拟执行每条指令，追踪每个寄存器的值集合（如标量区间、指针、指针算术范围）与栈状态。它维护一个"状态集"（寄存器 map + 栈 map），对分支合并状态，检测不可达路径。安全终止：验证器检查循环有界（所有循环必须有明确上界，通过追踪计数与无符号比较），防止无限循环；同时限制指令数、栈深度、辅助调用次数。内存安全：验证器追踪指针的来源与边界（如从 map 或栈派生），检查指针算术是否越界、解引用是否在合法范围，防止越界访问与类型混淆。通过抽象解释，验证器在运行前证明程序满足安全属性。

验证器用抽象解释模拟程序执行，追踪寄存器/栈状态与指针边界，从而保证有限终止与内存安全。这是 eBPF 安全性的核心：在加载期验证而非运行期。

• 理解 CO-RE 机制
• 理解 BTF-based relocation
• 理解跨内核版本适配

BTF（BPF Type Format）是内核与 BPF 程序的类型信息格式，描述结构体布局、字段偏移等。CO-RE（Compile Once – Run Everywhere）使 BPF 程序在编译一次后可运行在不同内核版本：程序通过 BTF 记录对内核结构字段的访问，编译时用占位符（如 __builtin_preserve_access_index）记录字段偏移，运行时通过 BTF 重定位（relocation）解析实际内核的字段偏移，从而适配不同内核结构体布局。内核提供 BTF（/sys/kernel/btf/vmlinux 或模块 BTF），libbpf 负责在加载时根据目标内核 BTF 修正访问偏移。这样无需针对每个内核版本重编译，只需重定位。

BTF 提供类型布局信息，CO-RE 用重定位在运行时修正字段偏移，实现"一次编译、到处运行"。核心是字段访问的偏移从编译期固定改为运行期由 BTF 解析。

• 理解 select 的 fd_set 拷贝
• 理解大连接数下的开销
• 理解与 epoll 的对比

select 每次调用：1) 将用户态的 fd_set（位图）复制到内核；2) 内核遍历所有 fd 检查就绪；3) 返回后内核将就绪结果写回 fd_set，用户需重置 fd_set 再调用。fd_set 大小固定（FD_SETSIZE，通常 1024），每次拷贝与遍历都是 O(n)（n 为注册 fd 数）。在大连接数下：1) 每次调用都要拷贝整个位图（即使只有少量连接就绪）；2) 内核线性扫描全部 fd 判断就绪；3) 返回后用户要重新设置 fd_set（FD_SET 重建），这是额外开销。相比之下 epoll 无需每次拷贝全部 fd，时间与活跃 fd 数相关。因此 select 在大连接数下因拷贝与扫描产生显著开销与扩展性差。

select 的 O(n) 拷贝与扫描在大连接数下显著。它无法增量维护，每次全量处理。epoll 用内核维护就绪链表避免全量扫描，是大连接数的正确选择。

• 理解 EPOLLONESHOT 语义
• 理解事件的一次性
• 理解重新注册

EPOLLONESHOT 使 epoll 事件在就绪一次后自动从就绪队列中移出（禁用该 fd 的后续触发），直到应用处理完重新用 EPOLL_CTL_MOD 重新注册。这样即使多个线程同时 epoll_wait，同一 fd 的事件只被唤醒一次、交付给一个线程，避免多个线程同时处理同一 fd 导致的数据竞争（如重复读、状态错乱）。特性：事件触发后 fd 被禁用（不再触发），需处理完手动重新使能；适合"每个 fd 绑定一个线程处理、处理完再交给下一个"的模型。与 EPOLLEXCLUSIVE 不同，EPOLLONESHOT 的作用是"一次就绪单次处理"，确保同一 fd 不被并发处理。

EPOLLONESHOT 的核心是"事件一次性交付"，防止多线程并发处理同一 fd。但它要求处理完重新注册，否则 fd 不再触发。这是多线程事件分发的重要模式。

• 理解编译期固定
• 理解高并发 fd 限制
• 理解运维影响

select 使用固定大小的 fd_set 位图，FD_SETSIZE 通常为 1024（可编译时重定义，但需重新编译程序）。这带来运维不便：1) 程序在编译时硬编码了可监控 fd 上限，若运行环境 fd 数超过 FD_SETSIZE，select 会越界（fd 值 >= FD_SETSIZE 时行为未定义，可能导致崩溃或内存破坏）；2) 无法动态调整上限，需重新编译程序；3) 高并发服务（连接数超过 1024）无法用 select 直接支持，需改用 poll/epoll 或提高 FD_SETSIZE 并重编译；4) 运维无法在运行时感知/修改该限制，扩展性受编译期约束。因此现代高并发服务普遍用 epoll 而非 select。

FD_SETSIZE 是编译期固定，运行期无法调整，导致运维需重新编译或改用 epoll。这是 select 的可扩展性硬伤，也是高并发场景弃用它的原因。

• 理解预读（readahead）
• 理解回收策略
• 理解三个提示的差异

madvise 提示内核如何处理指定内存区域的页。MADV_SEQUENTIAL 提示按顺序访问，内核可加大预读（readahead）深度，并优先回收已读过的页（因为这些页不再需要）；MADV_RANDOM 提示随机访问，内核减少或禁用预读（避免浪费），并可能不高优先级保留；MADV_WILLNEED 提示即将访问，内核主动预读（readahead）这些页到页缓存，减少后续缺页延迟。影响：MADV_SEQUENTIAL 优化顺序读的预读与回收，MADV_RANDOM 关闭预读避免浪费，MADV_WILLNEED 主动预读提升首次访问性能。这些是"提示"，内核按基于的压力与策略决定是否采纳。

三个提示分别对应"顺序读（预读+回收）、随机读（禁预读）、即将访问（主动预读）"。了解它们可针对性优化文件访问缓存行为。提示非强制，内核按策略采纳。

• 理解 SO_REUSEPORT 的连接分发层
• 理解两种缓解的层次
• 理解叠加使用

惊群发生在两个层面：唤醒层（多个 epoll_wait 等待同一 fd 被同时唤醒）与连接分发层（多个进程 accept 同一 listen fd 竞争）。EPOLLEXCLUSIVE 在唤醒层缓解：让内核只唤醒一个 epoll 等待者，解决"多个线程被同时唤醒"的无效唤醒。SO_REUSEPORT 在连接分发层缓解：允许多个 socket 绑定同一端口，内核按负载均衡（哈希/随机）把新连接分发到不同 socket/进程，每个进程独立 accept，避免竞争。两者可叠加使用：SO_REUSEPORT 让多个进程独立监听同一端口，EPOLLEXCLUSIVE 让每个进程内的 epoll 只唤醒一个等待者，从两个层面同时缓解惊群。

EPOLLEXCLUSIVE 解决"唤醒竞争"，SO_REUSEPORT 解决"accept 竞争"。两者层次不同，可叠加。叠加时多进程 + 多线程都能有效避免惊群。

• 理解统一事件循环
• 理解替代信号处理与 setitimer
• 理解 IO 复用整合

signalfd 将信号转换成一个可读 fd（读取得到 siginfo），timerfd 将定时器转换成可读 fd（定时器到期可读），eventfd 将事件计数转换成可读 fd（写入计数、读取返回计数）。三者都把"异步事件"统一为"可读 fd"，从而可与普通 socket/文件 fd 一起加入 epoll 事件循环，统一处理。优势：1) 替代传统信号处理（sigaction 回调），避免信号处理器的 async-signal-safe 限制与打断；2) 替代 setitimer/alarm 的定时器，定时器到期作为 fd 事件处理；3) 统一事件循环，无需多套机制。使用前需先 sigprocmask 阻塞信号（signalfd 才收到）。这样 epoll 统一管理网络、信号、定时器、事件计数。

三者的共同点是"把事件转化为可读 fd"。这使 epoll 能统一处理所有异步事件，替代信号处理器与 setitimer。signalfd 需先阻塞信号，避免信号被默认处理。

• 理解 io_uring 操作码
• 理解 IORING_REGISTER_PROBE
• 理解优雅降级

IORING_REGISTER_PROBE 用于探测当前内核 io_uring 支持的 opcode 集合。应用在启动时调用它，获得支持的 opcode 位图，据此决定是否使用某个操作码。若某 opcode 不支持（如 IORING_OP_SENDMSG 在旧内核缺失），应用应回退到传统路径：用 epoll 事件循环 + 对应系统调用（如 sendmsg），或使用 io_uring 的兼容操作（如 IORING_OP_READV）。优雅回退策略：1) 先探测 io_uring 是否可用（io_uring_setup 返回 ENOSYS 则整体回退到 epoll）；2) 用 REGISTER_PROBE 探测特定 opcode；3) 对不支持的 opcode 走 fallback 路径（系统调用或 epoll）；4) 设计抽象层，把"提交操作"与"等待完成"抽象，底层可切换 io_uring/系统调用。这样在新旧内核上都能运行。

IORING_REGISTER_PROBE 提供能力探测，回退策略是"探测+降级"。抽象层把 io_uring 与系统调用封装，按能力选择实现，保证兼容与优雅降级。

• 理解系统调用开销
• 理解批量提交
• 理解省去的路径

IORING_OP_READV/WRITEV 相比直接 preadv/pwritev 的优势：1) 系统调用开销：preadv/pwritev 每次都要用户态<->内核态陷阱（syscall，含 syscall 指令、上下文切换、参数拷贝），io_uring 通过共享内存环形队列（SQ/CQ）批量提交，避免每次 syscall 的陷阱，一次 io_uring_enter 可提交多个操作；2) 减少系统调用次数：批量提交/回收，摊薄 syscall 开销；3) 减少数据拷贝：io_uring 通过共享内存传递请求/完成，避免参数与结果的反复拷贝；4) 支持异步非阻塞，无需线程池。因此高吞吐场景 io_uring 通过批量提交与共享内存省去大量 syscall 与拷贝开销。

核心优势是"批量提交减少 syscall 次数 + 共享内存避免参数拷贝"。io_uring 用环形队列批量化，把多次 syscall 合并为一次，摊薄开销。这是性能提升的关键。

• 理解 map 操作约束
• 理解指针算术限制
• 理解 verifier 的静态检查

eBPF helper call 约束：只能调用内核预定义并授权的 helper 函数（如 bpf_map_lookup_elem、bpf_ktime_get_ns），不能调用任意内核函数；helper 的参数类型与权限由内核校验，部分 helper 需特定权限（如 CAP_SYS_ADMIN）。map 操作约束：只能访问已注册的 map，map 类型与 key/value 大小固定，访问受 map 定义约束；对 map 的并发访问需遵循 map 语义（如 per-CPU map）。verifier 限制指针算术：它追踪每个指针的"类型"（如 map 指针、栈指针、数据包指针）与"边界"，不允许把指针与任意标量乱加（只能用有界标量），不允许指针越界、指针与指针相减得非法值、把标量伪装成指针等。通过类型与边界追踪，运行期保证指针安全。

verifier 限制"能调什么 helper"与"指针怎么算"。helper 白名单 + map 约束 + 指针边界追踪，保证 BPF 程序不越界、不调用非授权函数。这是 eBPF 沙箱安全的核心。

• 理解 select 的 fd_set 位图
• 理解 O(n) 扫描
• 理解与 epoll 差异

select 的 fd_set 是位图，内核每次需遍历整个位图（0..FD_SETSIZE）检查每个 fd 是否就绪；poll 的 pollfd 数组内核需遍历所有提交的 pollfd 检查每个的状态。两者本质上都是"每次调用全量扫描所有注册 fd"，复杂度 O(n)（n 为 fd 数）。即便只有少量 fd 就绪，内核也无法跳过未就绪的，必须逐一检查。原因：select 和 poll 都是"无状态"的——每次调用把 fd 集合传给内核，内核重新遍历，不保存先前就绪状态。epoll 是"有状态"的——fd 注册后由内核维护，就绪时通过回调挂入就绪链表，epoll_wait 只返回活跃 fd，复杂度 O(活跃数) 而非 O(n)。因此 fd 增多时 select/poll 的 O(n) 扫描成为瓶颈。

select/poll 无状态、每次全量扫描，故 O(n)。epoll 有状态、就绪链表只返回活跃 fd，故 O(活跃数)。这是 epoll 在大连接数下更优的根本原因。

• 理解就绪链表
• 理解 epoll_wait 的返回
• 理解复杂度分析

epoll 用红黑树管理所有注册的 fd（增删为 O(log n)），用就绪链表（ready list）记录当前就绪的 fd。当 fd 就绪时，内核通过回调（ep_poll_callback）把 fd 挂入就绪链表。epoll_wait 只需把就绪链表中的活跃 fd 复制到用户数组返回，无需遍历所有注册 fd。因此 epoll_wait 的耗时与就绪链表长度（活跃 fd 数）成正比，而非注册总数。即使注册了十万 fd，若只有 10 个活跃，epoll_wait 也只返回 10 个。这是"有状态 + 回调驱动"的设计：就绪信息由内核实时维护，取用 O(活跃数)。

epoll 的核心是"就绪链表 + 回调驱动"，让 epoll_wait 只返回活跃 fd。红黑树负责注册管理，就绪链表负责实时交付。两者分离实现 O(活跃数) 的取用。

• 理解 ep_poll_callback
• 理解回调驱动
• 理解 C10K 缓解

当 fd 变得就绪（如数据到达）时，内核通过文件系统通知机制调用 ep_poll_callback 回调，该回调把对应的 epitem 挂入 epoll 事件的就绪链表（ready list），并唤醒等待的 epoll_wait。epoll_wait 从就绪链表取事件返回。这样内核无需每次扫描所有 fd，而是由就绪事件主动触发回调。C10K（万连接并发）问题：传统 select/poll 在万级连接下 O(n) 扫描成为瓶颈；epoll 通过红黑树管理注册 + 就绪链表回调驱动，事件处理时间与活跃连接数相关，使万级连接可高效处理。这是 epoll 缓解 C10K 的核心机制。

ep_poll_callback 是"就绪事件驱动"的关键：fd 就绪时主动回调入链表，而非等待全量扫描。回调驱动 + 就绪链表使 epoll 高效处理海量连接，解决 C10K。

• 理解边沿触发（ET）
• 理解 poll 的 LT 语义
• 理解模拟 ET

poll 返回当前所有就绪的 fd 状态（水平触发），只要 fd 仍就绪，后续 poll 调用会持续返回，不区分"是否新就绪"。poll 没有 ET 标志，无法区分"状态跳变"与"持续就绪"。要模拟边沿触发（在状态跳变时通知一次），应用需自行记录上次 poll 的就绪状态，本次 poll 后与前次比较：只在"上次未就绪、本次就绪"时处理，避免重复处理仍就绪的 fd。这需要应用维护每个 fd 的先前就绪位图，比较变化。缺点：仍要全量收集状态并比较，无法利用内核的边沿触发优化。epoll 的 EPOLLET 才是内核级 ET。

poll 只有 LT：持续就绪持续返回。模拟 ET 需应用自行"差分"前后就绪状态。这是 poll 无法提供内核级 ET 的体现，也说明 ET 需要内核状态记忆。

• 理解 MAP_PRIVATE
• 理解写时复制（COW）
• 理解回写语义

MAP_SHARED 映射的文件页共享给所有映射该文件的进程（同一物理页），任一进程写都会立即修改共享页，并可通过 msync 回写到磁盘文件，改动对其它映射进程可见。MAP_PRIVATE 映射使用写时复制（COW）：映射初始共享文件页，但任一进程写时复制出私有页，改动只对当前进程可见，不写回原文件，也不影响其他进程。典型用途：MAP_SHARED 用于进程间共享内存（如 IPC、共享缓存）、需持久化修改的文件映射；MAP_PRIVATE 用于从文件加载只读数据（如共享库、可执行文件映像，代码段）、需私有副本（如数据段）。区别核心：SHARED 共享且回写，PRIVATE 私有且不回写。

核心差异是"共享可见 + 回写" vs "私有 COW + 不回写"。MAP_SHARED 用于 IPC 与持久化，MAP_PRIVATE 用于只读加载与私有副本。SHARED 改动能持久化，PRIVATE 不能。

• 理解文件映射
• 理解 MAP_FIXED
• 理解危险性与替代

MAP_ANONYMOUS 映射不基于文件，来源为内核零页/匿名内存（用于分配大块内存、进程间共享匿名内存），无文件关联，MAP_SHARED 匿名映射用于共享内存。文件映射基于文件（map 文件到地址空间），来源为文件页缓存，可回写。MAP_FIXED 要求把映射放在指定地址（addr 精确），内核会覆盖该地址上已有的映射（可能破坏现有映射、库、栈），导致未定义行为或崩溃；且指定地址可能与已有映射冲突。危险性：MAP_FIXED 会"悄悄替换"已有映射，破坏程序状态。更安全替代：不指定 MAP_FIXED（内核选地址），或用 MAP_FIXED_NOREPLACE（Linux）在冲突时返回错误而非覆盖。

MAP_ANONYMOUS 无文件源、用于内存分配/共享；文件映射有文件源。MAP_FIXED 危险在于强制覆盖已有映射，可能破坏程序；用 MAP_FIXED_NOREPLACE 或让内核选地址更安全。

• 理解 mmap 与文件大小关系
• 理解 truncate 的影响
• 理解访问越界页

mmap 映射了文件的一部分，映射的长度基于映射时的文件大小，但文件内容可能被 truncate 缩短。当访问的页超出文件末尾（truncate 后文件变短，但映射仍保留原长度）或访问文件尾之后的部分页时，内核无法从文件页缓存填充该页（文件已无对应数据），如果该页是部分在文件内部分超出（partial page），访问超出部分也无法从磁盘读取，此时触发 SIGBUS（Bus error）而非 SIGSEGV。SIGBUS 表示"访问对象存在但无法访问/数据不可用"，区别于 SIGSEGV（地址不合法）。处理：需要检查文件大小变化，避免访问超出当前文件尾的映射区域，或使用 SIGBUS 处理或重新映射。

SIGBUS 源于"映射存在但文件数据不足"。truncate 后访问超出文件尾的页无法从磁盘填充，触发 SIGBUS。这与 SIGSEGV（地址非法）不同，需区分并安全处理。

• 理解 munmap 解除映射
• 理解 MS_SYNC 与 MS_ASYNC
• 理解回写时机

msync 将 MAP_SHARED 映射的修改同步回写到磁盘文件，用于保证持久化。MS_SYNC 同步等待回写完成（保证数据已写到磁盘后才返回）；MS_ASYNC 异步回写（发出回写请求后立即返回，不等待完成）。MS_INVALIDATE 使其它映射失效。munmap 解除映射，释放地址空间；对 MAP_SHARED 的修改，解除映射前需 msync 才能保证回写（否则仅在页缓存，可能随系统缓存丢失）。差别：MS_SYNC 阻塞等待回写完成，保证持久性；MS_ASYNC 非阻塞，提高性能但数据可能未落盘。对 MAP_PRIVATE 的修改不会被 msync 回写（私有副本不写文件）。

msync 负责回写，MS_SYNC 等待完成（强持久化）、MS_ASYNC 异步（高吞吐）。munmap 解除映射，MAP_SHARED 修改需 msync 才可靠持久化。理解回写时机是保证数据一致性的关键。

• 理解 signalfd 的机制
• 理解默认信号处理
• 理解错误使用后果

signalfd 通过读取 fd 来获取已排队/已阻塞的信号，但信号到达时若未阻塞，会触发默认的信号处理（如 SIGTERM 终止进程、SIGINT 中断），而不是被 signalfd 捕获。因此使用 signalfd 前必须先调用 sigprocmask/pthread_sigmask 阻塞该信号，使信号被挂起（pending）而非触发默认处理，然后 signalfd 才能读到该信号。若未阻塞：信号可能被默认处置杀进程（如 SIGTERM/SIGINT），或信号未进入 signalfd 队列，导致 signalfd 读不到。正确处理：先阻塞信号，再创建 signalfd 读取。

阻塞是让信号"挂起待处理"而非"触发默认处理"。signalfd 依赖阻塞后的 pending 信号。遗漏阻塞会导致信号被默认处置或无法被 signalfd 捕获。

• 理解 CQE 错误码
• 理解 -EOPNOTSUPP
• 理解回退策略

io_uring 的完成队列（CQE）返回 res 字段表示操作结果。res 为 -ENOSYS 表示系统调用/操作码不存在（如 io_uring_setup 不支持或某 opcode 未实现），说明该功能在当前内核不可用；-EOPNOTSUPP 表示操作不支持（如文件系统/设备不支持某操作）。这些错误的含义是"内核不支持该能力"，而不是"临时失败"。回退策略设计：1) 对 -ENOSYS（io_uring 整体不可用）回退到 epoll + 系统调用（传统路径）；2) 对 -EOPNOTSUPP 或特定 opcode 的 -ENOSYS，回退到同一操作的系统调用实现（如 IORING_OP_READV 回退 pread）；3) 用 IORING_REGISTER_PROBE 预先探测能力，避免盲目提交；4) 抽象层把"提交+等待"封装，底层按能力切换 io_uring 或系统调用。回退要保证语义一致（数据、错误、超时）。

-ENOSYS/-EOPNOTSUPP 是"能力缺失"信号，需回退而非重试。回退策略是探测能力 + 抽象层切换 + 语义一致。设计良好的回退使 io_uring 在新旧内核上都能优雅运行。

• 理解 IORING_OP_LINK_TIMEOUT
• 理解 timeout 与 link
• 理解使用场景

IORING_OP_TIMEOUT 在提交队列中插入一个超时操作，用于为整个提交批次或后续操作设置全局超时（若超时到期则超时操作就绪，可与其它事件竞争）。典型场景：批量 I/O 的全局时限（如聚合多个请求，超时后返回）。IORING_OP_LINK_TIMEOUT 与链式操作（link）结合，为前一个链接的操作设置超时：若前一个操作超时未完成，则超时操作触发并取消/标记前一个操作。典型场景：为单个网络/IO 操作设置超时（如 recv 超时），超时后取消该操作。区别：IORING_OP_TIMEOUT 是独立/全局计时，LINK_TIMEOUT 绑定链上前置操作。使用时需注意与 IO_LINK 标志配合。

IORING_OP_TIMEOUT 是批次级/全局超时，IORING_OP_LINK_TIMEOUT 是链路级操作超时。前者整体时限，后者为单个链上操作计时并取消。选择取决于"超时粒度"。

• 理解 socket filter 位置
• 理解 XDP 位置
• 理解性能差异来源

差异源于 BPF 程序所在的数据路径位置。socket filter（SO_ATTACH_FILTER）在接收路径的 socket 层执行，此时数据包已经过完整内核网络栈处理（包括协议栈、校验、队列、中断处理），BPF 程序看到的是已进入 socket 接受队列的数据，路径较"深"。XDP 钩子（XDP_PROG）在网卡驱动层面、数据包刚进入内核时（甚至网卡能力上的 XDP 硬件卸载）执行，在协议栈处理之前，路径极"浅"，可早期丢弃（drop）、转发（redirect）或回环，避免协议栈处理开销。因此同一 BPF 程序在 XDP 上性能更高（更早、更轻的路径），socket filter 在较深路径上执行，开销更大但功能更贴近应用层。性能差异来自"执行点深度"与"是否经过协议栈"。

XDP 在驱动层、协议栈之前，可早期处理；socket filter 在协议栈之后。执行点越浅，规避的协议栈开销越多，性能越高。这是 XDP 高性能的核心。

• 理解 BPF 指令数上限
• 理解 tail call
• 理解拆分策略

BPF 程序有指令数上限（如特权进程可达 100 万条，普通程序上限较小），大型程序可能超限。拆分策略：1) 子程序（subprog）：把逻辑拆成多个函数，用 bpf_call 调用，verifier 支持非递归子程序，降低单程序指令数，可复用代码；2) tail call（bpf_tail_call helper）：把程序拆成多个独立的 BPF 程序，通过 tail call 在运行时跳转到另一个程序（用程序映射 bpf_prog_array 索引），实现"分段执行"，每个程序独立受指令数限制，但可串联执行。tail call 不创建新栈帧（复用当前栈），适合分阶段处理。组合：用子程序组织代码、用 tail call 分阶段处理大任务，突破单程序指令数限制。

子程序用 bpf_call 复用代码、降低指令数；tail call 用 bpf_tail_call 分阶段跳转、每段独立。两者结合可突破指令数上限，实现大型 BPF 逻辑。

• 理解边沿触发（ET）
• 理解编程模型差异
• 理解 ET 的注意事项

水平触发（LT）：只要 fd 仍就绪，epoll_wait 就持续返回该事件，即使未处理完，下次仍会通知。编程模型简单：可一次读一部分，未读完的后续仍会触发，不易漏读，但可能重复唤醒。边沿触发（ET）：只在 fd 状态从"未就绪"变为"就绪"（跳变）时通知一次，之后即使未处理完也不再通知，直到再次发生状态跳变。编程模型要求：必须在一次通知中读尽所有数据（循环读直到 EAGAIN），否则会漏读；通常配合非阻塞 fd。ET 减少重复唤醒、效率高，但要求应用处理 EAGAIN 与全量读取。选择：LT 简单可靠，ET 高效但复杂。

LT 是"持续就绪持续通知"，ET 是"状态跳变通知一次"。ET 要求读尽数据（直到 EAGAIN），否则漏读。编程模型差异在于"是否要处理未读完的持续通知"。