操作系统基础

内容模块

OS 核心机制

进程、线程、协程：资源边界和调度主体

操作系统面试里，进程、线程、协程不是三个孤立定义，而是三种不同层次的执行模型。核心问题是：谁拥有资源，谁被内核调度，谁在用户态切换。

概念	资源边界	调度者	切换成本	适合场景	典型风险
进程	独立虚拟地址空间、文件描述符、信号处理、资源限制	内核	最高	强隔离、多服务、多 worker、容器主进程	IPC 成本高，共享状态复杂
线程	共享进程地址空间，独立栈和寄存器上下文	内核	中等	CPU 并行、I/O 并发、推理 worker pool	锁竞争、数据竞争、死锁、false sharing
协程	运行在线程内，共享进程/线程资源	用户态 runtime	最低	高并发 I/O、异步 RPC、事件循环	阻塞调用会卡住调度线程，不能自动利用多核

进程是资源隔离单位，线程是内核调度单位，协程是用户态调度的轻量执行单元。

上下文切换到底切什么

切换类型	需要保存/恢复	代价来源	排查信号
进程切换	寄存器、内核栈、页表/地址空间、调度状态	TLB 失效、cache 污染、内核调度	`pidstat -w`、`vmstat cs`
线程切换	寄存器、线程栈、调度状态	内核调度、cache 污染、锁等待	`top -H`、`perf sched`
协程切换	用户态栈/状态机、少量寄存器	runtime 调度，通常无需内核态	runtime profiler、事件循环延迟

Q: 进程、线程、协程有什么区别？面试怎么回答？

回答思路：先按资源隔离、调度主体和切换成本三条线回答，再补适用场景。

进程

进程拥有独立地址空间和资源边界，隔离性最好，适合服务拆分和容器主进程，但跨进程通信成本较高。

线程

线程共享进程地址空间，是内核实际调度的执行实体，适合多核并行，但需要处理锁、数据竞争和死锁。

协程

协程是用户态调度的轻量执行单元，适合 I/O 密集和高并发，但单个线程内的协程不能自动利用多核，阻塞调用会影响整个调度线程。

面试口径：进程看隔离，线程看并行，协程看轻量异步；不要只背定义，要说出调度和资源边界。

CPU 调度算法：从单机 OS 到集群调度的共同语言

CPU 调度回答“下一个时间片给谁”。这些算法也会迁移到 K8s、HPC 和 AI 集群里：FIFO 对应队列顺序，SJF 对应短任务优先，RR 对应租户轮转，优先级对应抢占，CFS 对应公平份额。

常见调度算法对比

算法	规则	是否抢占	优点	缺点	AI Infra 类比
FIFO / FCFS	先到先服务	通常非抢占	简单、按到达顺序公平	队头阻塞	训练队列按提交时间排队
SJF	运行时间短的先跑	通常非抢占	降低平均等待时间	需要预测，长任务可能饥饿	短实验优先、预测驱动调度
SRTF	剩余时间最短优先	抢占式	动态到达下等待时间更低	抢占成本高	checkpoint-aware preemption
Round Robin	按时间片轮转	抢占式	响应性好，避免独占	时间片难选，切换开销	队列/租户轮转
优先级调度	高优先级先运行	可抢占或非抢占	表达业务重要性	低优任务可能饥饿	PriorityClass、队列优先级
CFS	按虚拟运行时间公平分配 CPU	抢占式	兼顾公平和交互响应	不是硬实时	公平份额、quota、dominant share

抢占式调度 vs 非抢占式调度

维度	抢占式	非抢占式
定义	调度器可以打断正在运行的任务	任务主动阻塞、退出或让出 CPU 才切换
响应性	高，适合交互和高优任务	低，可能被长任务卡住
开销	上下文切换更频繁	切换少，实现简单
集群类比	抢占低优训练任务，可能回滚 checkpoint	不抢占更稳定，但高优任务等待更久

CFS 深挖：vruntime、权重和 runqueue

CFS（Completely Fair Scheduler）的核心思想是：不要只按固定时间片轮转，而是持续维护每个 runnable task 已经获得的“公平份额”。它用 vruntime 表示加权后的虚拟运行时间，倾向于选择 vruntime 最小的任务运行。

概念	含义	面试解释
`vruntime`	加权虚拟运行时间	越小表示相对越“没跑够”，越应该获得 CPU
nice / weight	优先级权重	权重越高，同样真实运行时间带来的 `vruntime` 增长越慢
runqueue	可运行任务队列	每个 CPU 有自己的可运行任务集合，CFS 按 `vruntime` 组织任务
抢占	打断当前任务	新唤醒任务或更小 `vruntime` 任务可能触发重新调度
上下文切换	保存/恢复执行状态	线程过多、频繁阻塞唤醒会让 CPU 时间浪费在切换上

CFS 的目标是公平和响应性，而不是让某一个任务吞吐最大。这个点和 GPU 的 warp/block 调度形成鲜明对比：GPU kernel 内部通常不追求每个 CUDA thread 的公平时间片，而是追求 SM 吞吐、occupancy 和隐藏内存延迟。

和 CUDA 调度的层次区别

Linux CFS 调度的是 OS task；CUDA Stream/Event 管的是 GPU 任务队列和依赖；CUDA block/warp 调度管的是 kernel 内部如何映射到 SM。这三层经常被混淆。

CFS

进程/线程共享 CPU 时间，强调公平和响应性

Stream/Event

组织 H2D、kernel、D2H 的异步顺序和依赖

Block → SM

GPU 把 grid 里的 block 分配到 SM 执行

Warp Scheduler

SM 选择 ready warp 发射指令，隐藏访存延迟

Q: 为什么 SJF 可以降低平均等待时间？有什么问题？

直觉：短任务放前面，只会让长任务多等一个短任务时间；长任务放前面，会让所有短任务都等一个长任务时间。因此短任务优先能降低平均等待。

问题

SJF 需要知道或预测运行时间，并且会让长任务饥饿。工程上通常用 aging、配额保障或最大等待时间兜底。

面试口径：说最优性时必须补前提和饥饿问题。

Q: Linux CFS 和 CUDA thread block 调度有什么区别？

CFS 是 CPU 上的操作系统调度器，调度对象是进程或线程，目标是公平性、响应性和 CPU 时间共享；CUDA thread block 调度是 GPU kernel 内部的硬件执行机制，调度对象是 grid 中的 block/CTA，目标是把 block 分配到 SM、让 warp scheduler 用 ready warp 隐藏访存延迟。CFS 通过 vruntime、权重、抢占和上下文切换决定哪个 task 运行；CUDA block 一旦驻留 SM 通常运行到完成，SM 内部以 warp 为单位发射指令，更强调吞吐而不是公平时间片。

CFS 管 OS task 的公平 CPU 时间，CUDA block/warp 调度管 kernel 内部的高吞吐并行执行。

虚拟内存：每个进程一套“假地址”

虚拟内存让每个进程都以为自己独占一整块连续地址空间。CPU 访问的是虚拟地址，由 MMU 通过页表翻译成物理地址。这带来三个核心价值：进程间隔离、地址空间比物理内存大（靠换页）、按需分配与共享。

能力	机制	意义
隔离	每进程独立页表	一个进程访问不到另一个进程内存
超额使用	page fault + swap	虚拟空间可大于物理内存
按需/延迟	lazy allocation、COW	malloc 不立刻占物理页，fork 不立刻拷贝
共享	多进程映射同一物理页	共享库、共享内存

分页与地址翻译

内存被切成固定大小的页（通常 4KB），物理内存切成同样大小的页框。页表记录“虚拟页 → 物理页框”的映射。现代 64 位系统用多级页表（如 x86-64 四级）避免单级页表过大。

虚拟地址

拆成页号 + 页内偏移

查 TLB

命中则直接得到物理页框（快）

查页表

TLB miss 时逐级走页表（page walk）

物理地址

页框号 + 偏移，访问物理内存

TLB 是页表的缓存。TLB miss 要走多级页表，代价高；这也是大页（HugePage）能提速的原因——同样内存用更少的页表项，TLB 覆盖更大。

缺页中断（Page Fault）三种类型

类型	触发	处理	代价
Minor（软）	页在内存但未建立映射（如 COW、共享页）	内核补页表项	低
Major（硬）	页不在内存，需从磁盘/swap 读入	发起磁盘 I/O 换入	高（毫秒级）
Invalid	访问非法地址	发 SIGSEGV，进程崩溃	段错误

排查信号：vmstat 的 si/so 列、/proc/<pid>/stat 的 majflt、perf stat 的 page-faults。Major fault 暴涨通常意味着内存不足开始 swap，P99 会剧烈抖动。

页面置换算法

算法	思想	问题
FIFO	先进先出	可能换出热点页，有 Belady 异常
LRU	淘汰最久未使用	精确实现成本高
Clock / 近似 LRU	用访问位环形扫描近似 LRU	Linux 实际采用的近似方案

Linux 用基于 active/inactive 链表的近似 LRU（带 second chance），而不是教科书纯 LRU，因为纯 LRU 维护开销太大。

和 AI Infra 的联系

虚拟内存机制直接影响大模型系统：① pinned memory（页锁定内存）禁止换页，才能让 GPU DMA 安全直传，是 H2D/D2H 拷贝提速的关键；② mmap 加载权重用按需缺页避免一次性读入巨大文件；③ HugePage/THP 减少 TLB miss，对大块连续访问的训练/推理负载有收益；④ 避免 swap，训练进程一旦触发 major fault 换页，吞吐会断崖式下降，所以训练节点通常关 swap。

Q: malloc 申请了 1GB 内存，物理内存马上就被占用了吗？

不会。malloc 通常只是扩大虚拟地址空间（建立映射区），并不立刻分配物理页。只有当你真正写入某一页时，才触发缺页中断由内核分配物理页框（lazy allocation / demand paging）。所以 top 里 VIRT（虚拟）远大于 RES（实际驻留物理）是正常的。

面试口径：虚拟内存是“承诺”，物理内存是“兑现”，兑现发生在第一次写入触发缺页时。

为什么需要 I/O 多路复用

核心矛盾：一个服务要同时处理成千上万条连接，但大部分连接在大部分时间是空闲的。如果“一连接一线程”，线程数会爆炸、上下文切换成本高；如果阻塞式单线程，一次只能服务一个连接。I/O 多路复用让单个线程用一次系统调用同时监听大量 fd，只在“就绪”时才去处理，是高并发服务器（Nginx、Redis、各类网关）的基石。

五种 I/O 模型（对比）

模型	阻塞点	特点
阻塞 I/O	read 一直等	最简单，一连接一线程
非阻塞 I/O	轮询返回 EAGAIN	忙等浪费 CPU
I/O 多路复用	阻塞在 select/poll/epoll	一个线程管多个 fd，主流方案
信号驱动 I/O	不阻塞，靠 SIGIO 通知	实际很少用
异步 I/O (AIO)	完全不阻塞，内核完成后通知	Linux io_uring 是现代代表

前四种都属于“同步 I/O”：数据从内核拷到用户态那一步仍由进程自己等。只有 AIO 是真正的异步。

select / poll / epoll 对比

维度	select	poll	epoll
fd 上限	FD_SETSIZE（通常 1024）	无硬上限	无硬上限
数据结构	位图 fd_set	pollfd 数组	内核红黑树 + 就绪链表
每次调用开销	O(n) 拷贝+遍历全部 fd	O(n) 拷贝+遍历全部 fd	O(1) 注册，O(就绪数) 返回
就绪通知	返回后需自己遍历找就绪	同 select	直接返回就绪 fd 列表
触发模式	仅水平触发(LT)	仅水平触发(LT)	支持 LT 和边缘触发(ET)

关键区别：select/poll 每次调用都要把全部 fd 从用户态拷到内核态并线性扫描；epoll 把 fd 注册一次常驻内核红黑树，事件就绪时由回调挂到就绪链表，epoll_wait 只返回就绪的 fd，因此在海量连接、少量活跃的场景下性能远超前两者。

epoll 三个核心系统调用

调用	作用
`epoll_create`	创建 epoll 实例，返回 epfd（内核里建红黑树 + 就绪链表）
`epoll_ctl`	对某个 fd 做 ADD / MOD / DEL，注册关心的事件
`epoll_wait`	阻塞等待，返回已就绪的 fd 列表

水平触发 LT vs 边缘触发 ET

维度	LT（水平触发）	ET（边缘触发）
通知时机	只要缓冲区还有数据就一直通知	仅在状态从无到有变化时通知一次
编程难度	简单，可以只读一部分	必须循环读到 EAGAIN，否则丢事件
性能	可能重复唤醒	唤醒次数少，配非阻塞 fd 用
典型用法	默认、上手快	Nginx 等高性能服务器

ET 必须搭配非阻塞 socket，并在每次事件里把数据一次性读干（直到 EAGAIN），否则剩余数据不会再被通知，连接“假死”。

Reactor 模式与 AI Infra 关联

Reactor 是基于 I/O 多路复用的事件驱动架构：一个事件循环（event loop）用 epoll 监听所有 fd，事件就绪后分发给对应 handler。这是 Netty、Redis、Nginx、各类 RPC 框架的通用骨架。

在 AI Infra 里这套模型同样无处不在：推理服务网关、参数服务器、KV 存储、调度器的 watch 机制，本质都是“少量线程 + epoll 事件循环”处理海量并发连接。理解 epoll 是看懂这些高性能组件的前提。io_uring 则进一步把网络/磁盘 I/O 改成真正的异步提交-完成队列，减少系统调用次数，是新一代高吞吐 I/O 的方向。

Q: epoll 为什么比 select/poll 高效？

三个关键：

避免重复拷贝

select/poll 每次调用都要把全部 fd 集合从用户态拷到内核态；epoll 用 epoll_ctl 注册一次，fd 常驻内核红黑树。

避免全量遍历

select/poll 返回后要 O(n) 扫描所有 fd 找就绪的；epoll 用回调把就绪 fd 挂到就绪链表，epoll_wait 直接返回就绪列表，复杂度只和活跃连接数相关。

支持 ET

边缘触发能减少无效唤醒。

面试口径：在“连接多、活跃少”的 C10K/C100K 场景下，epoll 的优势最明显；连接很少且都活跃时三者差距不大。

Q: epoll 一定比 select 快吗？

不一定。epoll 的优势来自“海量 fd 中只有少量活跃”。如果监听的 fd 很少（比如几十个），或者几乎所有 fd 每次都活跃，epoll 的红黑树维护和回调开销反而不一定占便宜，此时 select/poll 足够。选型要看连接规模和活跃比例。

死锁：四个必要条件

死锁是指一组进程/线程互相持有对方需要的资源，谁都无法继续。下面四个条件同时满足才会发生，破坏任意一个即可预防。

条件	含义	破坏方式
互斥	资源同一时刻只能被一个持有	资源可共享化（多数难破坏）
持有并等待	持有资源的同时等待新资源	一次性申请全部资源
不可剥夺	资源不能被强行抢走	允许超时释放、可抢占
循环等待	存在环形等待链	按全局固定顺序加锁

工程上最常用、最实用的手段是破坏“循环等待”——所有线程按统一顺序加锁。

处理策略：预防 / 避免 / 检测 / 恢复

策略	做法	代价
预防	破坏四条件之一（如固定加锁顺序）	降低并发或资源利用率
避免	运行时判断是否进入不安全状态（银行家算法）	需预知最大需求，实际少用
检测	构建资源分配图找环	检测有开销
恢复	杀进程、回滚、抢占资源	有副作用，需可重试

大多数业务系统采用预防 + 超时：统一加锁顺序避免大部分死锁，再用锁超时（try_lock + 超时回退）兜底，而不是上线复杂的银行家算法。

经典死锁代码（加锁顺序不一致）


// 线程 A: lock(mutex1) -> lock(mutex2)
// 线程 B: lock(mutex2) -> lock(mutex1)   <-- 顺序相反，可能死锁

// 修复：所有线程统一按地址/ID 顺序加锁
std::lock(mutex1, mutex2);            // C++ 一次性获取，避免顺序问题
std::lock_guard g1(mutex1, std::adopt_lock);
std::lock_guard g2(mutex2, std::adopt_lock);

死锁排查与活锁/饥饿区分

现象	特征	排查/区分
死锁	线程互相等待，CPU 不忙但卡死	`gdb` / `pstack` 看线程栈都停在 lock；`jstack`（Java）能直接报 deadlock
活锁	线程不停重试却都没进展，CPU 很忙	加随机退避打破对称
饥饿	某线程长期抢不到资源	用公平锁、优先级 aging

和 AI Infra / 分布式的联系

死锁不只在单机锁里出现：① 分布式训练中，集合通信（如 NCCL all-reduce）要求所有 rank 都参与，如果某个 rank 因异常没进入通信原语，其他 rank 会一直等待，表现为整作业 hang（本质是分布式死锁/挂起）；② 资源调度中，多个大作业各占一部分 GPU 又都等不到完整资源，形成资源死锁，需靠 gang scheduling（要么全给要么不给）破解；③ 数据库/分布式锁跨服务加锁顺序不一致同样会死锁。排查训练 hang 常用 py-spy dump / 看各 rank 卡在哪一步。

Q: 如何预防死锁？工程上最实用的办法是什么？

理论上破坏四个必要条件之一即可，但互斥和不可剥夺往往难破坏。工程上最实用的是破坏循环等待：给所有锁定义全局顺序，任何线程都按同一顺序加锁，环就不可能形成。再辅以锁超时 + 可重试兜底，以及减小锁粒度、缩短临界区、能用无锁结构就用无锁。

面试口径：先说四条件，再落到“统一加锁顺序 + 超时回退”这种可落地的方案，比背银行家算法更有说服力。

Q: 分布式训练任务 hang 住了，可能和死锁有什么关系？

集合通信是同步屏障，要求所有 rank 一起到达。如果某个 rank 提前报错退出、走了不同的代码分支、或数据加载卡住没进入 all-reduce，其余 rank 会在通信原语上无限等待，整个作业 hang——这是一种分布式层面的“互相等待”。排查时用 py-spy/栈抓取看各 rank 卡在哪，常见根因是 rank 间逻辑分支不一致或某卡 OOM/异常。

内存问题不是只看容量

内存排查要同时看系统内存、cgroup limit、GPU 显存、NUMA locality、page cache、swap、带宽和碎片。容量够不代表没有瓶颈。

内存问题基础模型

维度	看什么	典型问题	排查入口
容量	系统内存、cgroup、GPU 显存	OOMKilled、CUDA OOM	`free -h`、`memory.current`、`nvidia-smi`
带宽	内存/HBM 吞吐	容量够但吞吐低	`perf`、DCGM、Nsight
延迟	page fault、swap、远端 NUMA	P99 抖动	`vmstat`、`numastat`
局部性	CPU/GPU/NIC 是否同 NUMA 域	跨 socket 访问慢	`numactl -H`、`nvidia-smi topo -m`

OOM、CUDA OOM 和 cgroup OOM

类型	资源池	触发者	现象
系统 OOM	宿主机内存	Linux OOM killer	进程被 kill，dmesg 有记录
cgroup OOM	容器 memory limit	cgroup memory controller	Pod OOMKilled
CUDA OOM	GPU 显存	CUDA runtime / 框架 allocator	程序抛 CUDA out of memory

Q: NUMA 是什么？为什么机器内存没用完也可能 OOM 或变慢？

NUMA 是 Non-Uniform Memory Access。多 socket 机器上，每个 CPU socket 有本地内存控制器，访问本地内存快，访问远端内存慢。进程可能被 cpuset、membind、cgroup 或 hugepage 池限制，只能使用部分内存；即使宿主机总内存没用完，也可能因为本地 NUMA node 不足或碎片导致分配失败。

面试口径：机器总内存、当前 cgroup 可用内存、本地 NUMA 内存、GPU 显存是不同资源池。

Signal：进程控制的异步通知机制

Signal 是内核投递给进程的异步事件，可用于终止、暂停、恢复、用户中断、非法访问、定时器和子进程状态变化。

常见 Signal

Signal	含义	是否可捕获	典型场景
SIGTERM	请求进程优雅退出	是	K8s 删除 Pod、systemctl stop
SIGKILL	强制杀死	否	grace period 超时
SIGINT	用户中断	是	Ctrl-C
SIGSEGV	非法内存访问	可捕获但通常不恢复	C/C++ 指针错误
SIGCHLD	子进程退出	是	父进程回收子进程

stdin/stdout/stderr

通道	fd	用途	容器/K8s 含义
stdin	0	输入	交互式 exec 或管道输入
stdout	1	正常输出	容器日志采集主通道
stderr	2	错误和 warning	容器日志采集主通道

Q: K8s 删除 Pod 时为什么先 SIGTERM 后 SIGKILL？

先发 SIGTERM 是为了给应用优雅退出机会：停止接新请求、处理完存量请求、flush 日志、保存状态、释放锁。超过 terminationGracePeriodSeconds 仍未退出时，再发不可捕获的 SIGKILL 强制回收资源。

面试口径：SIGTERM 是协商退出，SIGKILL 是强制回收。

内容模块

AI Infra 系统视角

AI Infra 面试模块：进程、线程与并发模型

AI Infra 面试里，进程、线程和协程不是概念背诵题，而是资源隔离、调度成本、数据加载吞吐和推理服务并发模型的基础。

核心概念定义

概念	定义	面试重点
进程	操作系统分配资源的基本单位，有独立虚拟地址空间、文件描述符表、信号处理和权限上下文。	隔离性强，崩溃影响小；创建和切换成本高于线程。
线程	进程内的执行流，共享进程地址空间和打开文件，拥有独立栈、寄存器上下文和调度状态。	通信方便、切换较轻；需要处理锁竞争、数据竞争和内存安全。
协程	用户态轻量执行流，由语言运行时或框架调度，通常用于大量 I/O 等待型并发。	切换不必进入内核；阻塞系统调用会阻塞承载线程，必须配合非阻塞 I/O。
IPC	进程间通信机制，包括 pipe、socket、shared memory、message queue、signal。	共享内存最快但同步复杂；socket 通用但有拷贝和协议开销。
同步原语	mutex、rwlock、semaphore、condition variable、barrier 等。	要能说明互斥、通知、资源计数、阶段同步分别适合什么场景。

需要掌握

进程与线程的区别：地址空间、资源隔离、崩溃影响范围、上下文切换成本。
用户态线程与内核态线程的区别：用户态切换快，内核态线程可被 OS 真正调度到多核。
多进程、多线程在 CPU 密集型和 I/O 密集型任务中的适用场景。
线程池为什么存在：避免频繁创建销毁线程，限制并发度，保护下游资源。
协程为什么适合网络服务：大量连接多数时间在等待 I/O，用少量线程承载大量逻辑执行流。
死锁产生条件：互斥、占有且等待、不可剥夺、循环等待。

上下文切换成本来自哪里

上下文切换要保存和恢复寄存器、程序计数器、栈指针、调度状态。进程切换还可能切换地址空间和页表，破坏 TLB；线程切换虽然共享地址空间，但仍会破坏 cache locality。大量线程竞争锁或频繁阻塞唤醒，会导致 CPU 时间消耗在调度和内核态，而不是业务计算。

AI Infra 相关关注点

DataLoader 多进程加载数据可以绕过 Python GIL，但会引入进程间队列、pickle/IPC、shared memory 和 copy-on-write 成本。
Python GIL 会限制纯 Python CPU 密集型多线程并行，训练框架常用多进程、C++ 后端释放 GIL、CUDA 异步执行来绕过。
推理服务常用线程池处理 tokenizer、detokenizer、网络收发、日志和业务逻辑；线程过多会造成 context switch 和锁竞争。
CPU 线程数、NUMA 绑核、DataLoader worker 数量会影响 GPU feeding，CPU 准备 batch 不连续会让 GPU 周期性空转。
多 worker 数据预处理要关注队列深度、worker 异常退出、共享内存大小和主进程是否及时消费。

高频问题

Q: 进程和线程有什么区别？什么时候用多进程，什么时候用多线程？

进程是资源分配单位，线程是执行调度单位。进程有独立地址空间，隔离性强，适合强隔离、绕过 GIL、崩溃不互相影响的场景；线程共享地址空间，通信方便，适合 I/O 密集、共享状态多、延迟敏感的服务。AI Infra 中，Python 数据预处理常用多进程，推理服务前后处理和网络收发常用线程池或协程。

Q: mutex 和 semaphore 的区别是什么？

mutex 是互斥锁，用来保护临界区，一般强调谁加锁谁解锁；semaphore 是计数信号量，用来表示可用资源数量，可以允许多个执行流同时进入。连接池容量、GPU slot、队列容量更像 semaphore；共享 map、调度器状态更新更适合 mutex/rwlock。

Q: Python 多线程为什么不能很好利用多核 CPU？

CPython 有 GIL，同一时刻通常只有一个线程执行 Python bytecode，所以纯 Python CPU 密集型多线程不能真正并行利用多核。但 I/O 阻塞、C++ 扩展、CUDA kernel launch 等可能释放 GIL，因此训练框架常通过 C++/CUDA 后端、多进程 DataLoader 和异步 pipeline 提升吞吐。

AI Infra 面试模块：内存管理

AI Infra 的内存问题往往同时涉及虚拟内存、物理内存、page cache、cgroup limit、shared memory、NUMA locality 和 GPU pinned memory。面试回答要能把 Linux 内存机制和训练/推理场景联系起来。

需要掌握

虚拟内存、物理内存、地址空间：进程访问虚拟地址，MMU 通过页表翻译成物理地址。
分页、页表、TLB、缺页中断：页表保存映射，TLB 缓存地址翻译，缺页中断负责按需分配或换入。
mmap：把文件或匿名内存映射到进程虚拟地址空间，访问时按需触发 page fault。
copy-on-write：fork 后父子进程共享物理页，写入时才复制。
堆、栈、内存碎片、内存泄漏：堆用于动态分配，栈用于函数调用，泄漏会让 RSS 持续增长。
malloc/free 基本思路：用户态 allocator 管理空闲块，必要时通过 brk 或 mmap 向内核申请。
page cache 与 buffer cache：Linux 用空闲内存缓存文件内容，提高重复读取性能。
swap：内存压力下把匿名页换出到磁盘，但训练/推理任务触发 swap 通常会导致吞吐断崖式下降。
NUMA：本地内存访问快，远端内存访问延迟高、带宽低。

关键指标

指标	含义	排查意义
VIRT / VMS	虚拟地址空间大小	大不代表真实占用物理内存。
RES / RSS	实际驻留物理内存	判断进程真实内存压力的关键。
SHR	共享页	共享库、mmap 权重、shared memory 都会体现在这里。
Page Cache	文件缓存	看似占满内存，但通常可回收。
Major Fault	需要磁盘 I/O 的缺页	权重加载慢、训练抖动的重要信号。
Minor Fault	不需要磁盘 I/O 的缺页	匿名页分配、COW、已有页重新映射。

AI Infra 相关关注点

大模型训练中的 CPU 内存、GPU 显存、page cache 之间是联动的：CPU 数据准备慢会饿死 GPU，GPU 显存不足会 OOM，page cache 不足会让重复读数据变慢。
mmap 加载大模型权重可以避免一次性读取全文件，支持多进程共享 page cache，但访问时可能触发 page fault，导致启动抖动。
fork DataLoader 时，父进程中已有的大对象初始会 COW 共享；worker 一旦写入对象，物理内存会复制，RSS 可能突然增大。
OOM 定位要区分进程 RSS、VMS、shared memory、page cache、cgroup memory limit、宿主机 OOM 和容器 OOM。
NUMA 绑定不合理会让 CPU worker 访问远端内存，或者跨 socket 给 GPU 准备数据，导致吞吐下降。

Linux OOM 与容器 OOM

宿主机 OOM 是整机内存压力下由内核 OOM killer 选择进程杀掉；容器 OOM 是 cgroup memory limit 被突破，内核在该 cgroup 内杀进程。容器中 page cache、shared memory、DataLoader worker、日志 buffer、主进程 RSS 都可能共同顶满 limit。

高频问题

Q: 虚拟内存解决了什么问题？

虚拟内存提供进程隔离、连续地址空间、按需分配、换页、共享库和 mmap 能力。它让进程看到自己的虚拟地址空间，由 MMU 和页表映射到物理内存。代价是地址翻译需要 TLB/page table，缺页会进入内核，major fault 还会触发磁盘 I/O。

Q: malloc 后一定立刻占用物理内存吗？

不一定。malloc 可能只是分配虚拟地址或复用 allocator 的空闲块，物理页通常在第一次写入时通过缺页中断分配。可以概括为：虚拟内存是承诺，物理内存是触碰页面后兑现。

Q: page cache 为什么会让内存看起来“被占满”？

Linux 会尽量用空闲内存缓存文件页，提升后续读取性能，所以 free 看到的空闲内存可能很少。但 page cache 通常是可回收的，内存压力来时可以释放。排查时要看 available、cache、cgroup limit 和真正不可回收的 RSS。

AI Infra 面试模块：文件系统与 I/O

文件系统与 I/O 直接影响训练数据加载、checkpoint 保存、模型权重加载和推理服务吞吐。面试中要能从文件抽象讲到内核路径，再落到性能瓶颈定位。

需要掌握

inode、目录项、文件描述符：inode 保存文件元数据和数据块位置，目录项把文件名映射到 inode，fd 是进程打开文件后的句柄。
buffered I/O：read/write 经过 page cache，适合复用和小块读取。
direct I/O：绕过 page cache，适合应用自管缓存的大文件顺序读写，但要求 buffer、offset、size 对齐。
sync/async I/O：同步 I/O 调用方等待完成，异步 I/O 提交请求后由完成事件通知。
read/write、pread/pwrite、mmap：pread/pwrite 带 offset 且不改变文件偏移，适合多线程并发读写。
dirty page 与 fsync：写入先进入 page cache 形成脏页，fsync 强制落盘，可能很慢。
顺序读写与随机读写：顺序访问利用预读和连续带宽，随机访问受寻址、队列深度和 metadata 影响。
SSD/NVMe：延迟低、并发队列强，但小 I/O、同步刷盘、文件碎片仍可能成为瓶颈。
I/O 多路复用：select、poll、epoll 让少量线程管理大量 fd。
零拷贝：sendfile、splice、DMA、mmap 等减少用户态/内核态拷贝和上下文切换。

一次 read 的典型路径

应用调用 read 进入内核；内核检查 fd、文件偏移和 page cache；如果命中，把 page cache 内容拷贝到用户 buffer；如果未命中，提交磁盘或网络存储 I/O，把数据读入 page cache，再拷贝给用户。这个路径可能慢在系统调用、page cache miss、磁盘 I/O、metadata、CPU copy、网络存储或文件格式解码。

AI Infra 相关关注点

训练数据读取瓶颈要拆成：磁盘/对象存储带宽、网络存储延迟、文件数量和 metadata、解码、数据增强、CPU worker、batch queue 深度。
小文件过多会导致 open/stat/readdir metadata 开销高，即使总数据量不大也会拖慢 DataLoader。
checkpoint 保存慢可能来自序列化、CPU 到磁盘写入、网络文件系统、fsync、单文件过大、并发写冲突。
模型权重加载时，mmap、顺序读、预读、page cache 预热、并行 shard 加载都会影响启动时间。
推理服务要把网络 I/O、请求解析、排队、batching、GPU 执行和响应写回解耦。
高吞吐服务常用 epoll/事件循环/异步 I/O/零拷贝降低线程数和拷贝成本。

训练时 GPU 利用率低，I/O 层怎么排查

看 GPU 利用率是否周期性掉到 0，如果是，常见原因是 batch feeding 不连续。
看 DataLoader worker CPU 是否打满，队列是否为空，是否被图像解码或数据增强拖慢。
用 iostat 看磁盘 util、await、吞吐；用网络监控看远端存储带宽和延迟。
看文件数量和单文件大小，小文件多时优先考虑打包格式或顺序读。
看 page cache 命中和 major fault，判断是否频繁从磁盘或网络存储重新取数据。

高频问题

Q: 文件描述符和 inode 的关系是什么？

inode 是文件系统中的文件元数据对象，文件名通过目录项映射到 inode。进程 open 文件后得到 fd，fd 指向内核 open file description，其中包含文件偏移和打开模式。多个 fd 可以指向同一个 inode，也可以共享或不共享文件偏移。

Q: epoll 相比 select/poll 的优势是什么？

select/poll 每次都要传入 fd 集合并线性扫描，epoll 把关注的 fd 注册到内核对象里，就绪事件通过 ready list 返回，避免每次全量扫描，更适合大量连接但少量活跃的高并发服务。

Q: fsync 为什么可能很慢？

write 返回通常只表示数据进入 page cache，不代表落盘。fsync 要等待脏页写回、文件系统 journal、设备 flush、网络存储确认和其他 I/O 排队。checkpoint 或日志频繁 fsync 会显著影响吞吐和延迟。

AI Infra 面试模块：CPU 调度与性能分析

AI Infra 里 CPU 不是“辅助资源”。数据预处理、tokenizer、detokenizer、请求调度、网络协议栈、NCCL 辅助线程、checkpoint 序列化都可能让 CPU 成为瓶颈。

需要掌握

进程调度基本原理：内核从 runnable 队列中选择下一个任务运行。
时间片、优先级、抢占、上下文切换：调度器在公平性、响应时间和吞吐之间取舍。
CPU load average 与 CPU utilization：load 包含 runnable 和不可中断睡眠任务；utilization 表示 CPU 实际忙碌比例。
user、system、iowait、steal：分别代表用户态执行、内核态执行、等待 I/O、虚拟化环境被宿主抢占。
cache locality、CPU cache、false sharing：线程迁移和共享 cache line 会影响吞吐。
软中断、硬中断：硬中断来自设备，软中断常用于网络包处理等延后工作。
perf、top、htop、pidstat、vmstat、sar 等工具的基本使用。

AI Infra 相关关注点

GPU 训练时 CPU 数据准备不足会让 GPU 空转。
高 QPS 推理服务中，CPU 前处理、tokenizer、JSON 序列化、日志和网络协议栈可能成为瓶颈。
多线程服务中锁竞争、上下文切换过高、cache miss 过高会导致吞吐下降和 p99 抖动。
容器环境下 CPU quota、cpuset、CFS throttling 会让服务“看起来还有 CPU”，但实际被限流。

load high 不等于 CPU busy

Linux load average 会统计 runnable 任务和 D 状态不可中断睡眠任务。大量任务卡在磁盘或网络 I/O，也会推高 load，但 CPU utilization 可能不高。因此判断 CPU 瓶颈要同时看 load、utilization、run queue、iowait、context switch 和线程栈。

高频问题

Q: load average 高是否一定说明 CPU 忙？

不一定。load 包含 runnable 和不可中断睡眠任务。I/O 卡住、网络存储慢、D 状态进程多都可能让 load 很高。要结合 CPU utilization、iowait、run queue 和 D 状态进程判断。

Q: iowait 高说明什么？

iowait 表示 CPU 空闲但系统中有任务在等 I/O。它提示 I/O 可能拖慢任务，但还要结合 iostat 的 await、util、吞吐和应用访问模式判断。训练中 iowait 高常见于数据集读取、checkpoint 或网络存储。

Q: 如何用 perf 分析 CPU hotspot？

先用 perf top -p <pid> 在线看热点，再用 perf record -g -p <pid> -- sleep 30 采样调用栈，最后用 perf report 或火焰图分析热点是在业务函数、系统调用、锁、内核网络栈、内存拷贝还是调度函数。

面试回答方法

遇到系统问题时先分四层，不要一上来只报命令：

业务现象

吞吐、延迟、失败率、GPU 空转

进程与容器

状态、线程、cgroup、OOM、FD、共享内存

主机资源

CPU、内存、NUMA、磁盘、网络

加速器与分布式

H2D、SM、HBM、NCCL、GPU 拓扑

Q: 容器 OOM 和宿主机 OOM 怎么区分？

先看 Pod termination reason、exit code 137 和事件，再看对应 cgroup 的 memory.current、memory.max 与 memory.events。如果进程触及容器 memory limit，通常是 cgroup 内 OOM；如果节点整体内存耗尽，则还要结合宿主机 dmesg、系统可用内存和其他进程判断。详细隔离机制放在“Linux 与容器”。

Q: GPU 利用率低为什么也可能是操作系统问题？

GPU 可能在等 CPU 解码、DataLoader、page fault、磁盘或网络 I/O，也可能因为 NUMA 放置不当导致 H2D 路径变长。OS 负责解释供给链为什么阻塞；SM Active、Warp Stall 和 NCCL 等 GPU 专项判断放在 GPU 与分布式训练页面。

常见误区

cgroup 能限制 CPU、内存和设备访问，不等于它能直接切分 GPU 的 SM 与 HBM。
显存占用高只说明资源常驻，不说明 GPU 正在高效计算。
top 中 CPU 不满不能排除单核热点、锁竞争、系统调用等待和 NUMA 问题。
mmap 不等于数据已经进入物理内存；首次访问仍可能触发缺页。

内容模块

复习优先级清单

精通★★★⏱ 15 min

准备方式与最小复习清单

面试前需要能把 OS 概念映射到 AI Infra 场景，并掌握覆盖常见故障的最小工具链。

第一层：概念准确

每个模块至少能解释：这个机制解决什么问题；核心原理是什么；有什么性能代价；它在 AI 训练或推理场景中如何体现。

第二层：能结合场景分析

GPU 利用率低如何排查。
DataLoader 很慢如何优化。
训练任务 OOM 如何定位。
推理服务 p99 延迟升高如何分析。
分布式训练通信慢如何定位。
checkpoint 保存很慢如何优化。
容器内任务被 OOM kill 如何排查。

第三层：熟悉工具链

top / htop
ps
free
vmstat
iostat
pidstat
sar
ss
lsof
strace
perf
dmesg
nvidia-smi

如果面试偏 Infra 或性能优化，建议进一步了解：

numactl
numastat
ethtool
tcpdump
bcc / bpftrace
nsenter
cgget / systemd-cgtop

最小复习清单

进程、线程、协程的区别。
线程同步、死锁、锁竞争。
虚拟内存、分页、缺页中断、TLB。
mmap、page cache、copy-on-write。
Linux OOM 与容器 OOM。
read/write、mmap、direct I/O 的区别。
epoll 原理与使用场景。
CPU load、utilization、iowait、context switch 的含义。
TCP 三次握手、四次挥手、TIME_WAIT。
namespace、cgroup、容器资源限制。
pinned memory、NUMA、PCIe topology 对训练性能的影响。
GPU 利用率低、服务延迟高、训练 OOM 的排查路径。

系统排查题回答模板

先界定现象：影响范围、开始时间、是否稳定复现、p50/p99/吞吐/GPU 利用率哪个变坏。
再分层拆链路：应用队列、CPU、内存、I/O、网络、GPU、容器限制、下游依赖。
用指标验证假设：用 top、pidstat、iostat、ss、strace、perf、nvidia-smi、日志和 trace 逐层收敛。
最后给优化方案：调参数、改并发模型、减少拷贝、增加缓存、调整 NUMA/绑核、优化 I/O 格式、扩容或限流。

OS 核心机制

进程、线程、协程：资源边界和调度主体

上下文切换到底切什么

CPU 调度算法：从单机 OS 到集群调度的共同语言

常见调度算法对比

抢占式调度 vs 非抢占式调度

CFS 深挖：vruntime、权重和 runqueue

和 CUDA 调度的层次区别

虚拟内存：每个进程一套“假地址”

分页与地址翻译

缺页中断（Page Fault）三种类型

页面置换算法

和 AI Infra 的联系

为什么需要 I/O 多路复用

五种 I/O 模型（对比）

select / poll / epoll 对比

epoll 三个核心系统调用

水平触发 LT vs 边缘触发 ET

Reactor 模式与 AI Infra 关联

死锁：四个必要条件

处理策略：预防 / 避免 / 检测 / 恢复

经典死锁代码（加锁顺序不一致）

死锁排查与活锁/饥饿区分

和 AI Infra / 分布式的联系

内存问题不是只看容量

内存问题基础模型

OOM、CUDA OOM 和 cgroup OOM

Signal：进程控制的异步通知机制

常见 Signal

stdin/stdout/stderr

AI Infra 系统视角

AI Infra 面试模块：进程、线程与并发模型

核心概念定义

需要掌握

上下文切换成本来自哪里

AI Infra 相关关注点

高频问题

AI Infra 面试模块：内存管理

需要掌握

关键指标

AI Infra 相关关注点

Linux OOM 与容器 OOM

高频问题

AI Infra 面试模块：文件系统与 I/O

需要掌握

一次 read 的典型路径

AI Infra 相关关注点

训练时 GPU 利用率低，I/O 层怎么排查

高频问题

AI Infra 面试模块：CPU 调度与性能分析

需要掌握

AI Infra 相关关注点

load high 不等于 CPU busy

高频问题

AI Infra 面试模块：网络基础与系统调用

需要掌握

AI Infra 相关关注点

高频问题

面试回答方法

常见误区

复习优先级清单

准备方式与最小复习清单

推荐准备方式

第一层：概念准确

第二层：能结合场景分析

第三层：熟悉工具链

最小复习清单

系统排查题回答模板