用户态和内核态
2026/7/23大约 4 分钟
在操作系统(如 Linux)中,用户态 (User Mode) 和 内核态 (Kernel Mode) 是 CPU 的两种运行级别(特权等级)。
操作系统之所以要这么划分,核心目的只有两个:安全与稳定。
为了让你秒懂,我们先用一个“银行办业务”的通俗比喻,再切入物理硬件的底层逻辑:
🏦 1. 通俗比喻:银行柜台 vs 办业务的顾客
- 内核态(Kernel Mode) 就像 银行的柜员。
- 他们坐在防弹玻璃后面(受保护的物理空间),手里有金库的钥匙、有权限直接操作系统的账户资金(直接控制 CPU、内存、硬盘、网卡等物理硬件)。
- 用户态(User Mode) 就像 来办业务的顾客。
- 顾客站在外面(受限空间),绝对不能自己走进程控室去抢钱或直接改账本(普通应用绝不能直接读写物理硬件)。
- 系统调用(System Call) 就像 银行窗口和业务申请单。
- 顾客(用户态程序)如果想存钱、取钱(写磁盘、发网络包),必须填写一张申请单,递交到窗口(发起系统调用),让柜员(内核态)帮你去操作。柜员办完后,再把结果隔着玻璃递给你。
💻 2. 物理与硬件层面的本质区别
在 CPU 的物理架构中(以 x86 为例),硬件设计了 4 个特权环(Privilege Rings),从 Ring 0 到 Ring 3:
Ring 3 [ 用户态 ] --> 普通应用程序 (PyTorch, Chrome, Nginx)
/
Ring 2 / 1 --> 几乎不用
/
Ring 0 [ 内核态 ] --> 操作系统内核、设备驱动
内核态 (Kernel Mode / Ring 0)
- 特权极高:CPU 可以执行所有的指令(包括修改 CPU 寄存器、控制中断、分配物理内存等),可以访问计算机的任何物理资源。
- 代表成员:Linux Kernel 本身、物理显卡驱动(NVIDIA Driver)、网卡驱动。
- 崩溃后果:一旦内核态的代码写错(比如指针越界),会直接导致 蓝屏 (Blue Screen) 或 系统死锁 (Kernel Panic),整台服务器直接挂掉。
用户态 (User Mode / Ring 3)
- 特权受限:CPU 只能执行安全的、受限的指令(比如算术运算、逻辑判断)。如果用户态程序尝试直接读写硬盘或显存,硬件层会直接触发“保护性异常”,强行终止该进程。
- 代表成员:你写的所有 Python 代码、PyTorch 训练任务、浏览器、K8s 的 kubelet。
- 崩溃后果:如果你的 PyTorch 发生 OOM 或段错误崩溃,它只会杀死这一个 Pod,操作系统内核依然完好无损,其他程序不会受到任何影响。
🔄 3. 两者是如何切换的?
当一个运行在用户态的程序(比如 PyTorch)需要读取训练数据集(存储在 SSD 上)时,必须经历一次状态切换(Context Switch,上下文切换):
- 用户态:PyTorch 执行到
read(file)。 - 陷阱/中断:CPU 触发软中断,保存当前的寄存器状态(记住 PyTorch 执行到哪了),将 CPU 特权级从 Ring 3 提升到 Ring 0。
- 内核态:操作系统内核接管,驱动程序控制 NVMe 硬盘把数据读入内核缓冲区。
- 拷贝数据:内核将数据从内核缓冲区拷贝到 PyTorch 申请的用户内存中。
- 返回:恢复 PyTorch 之前的寄存器状态,将 CPU 特权级从 Ring 0 降回 Ring 3,PyTorch 继续往下运行。
⚡ 4. 为什么 AI 算力调优总是跟它们“过不去”?
在普通的 IT 场景下(比如写个网页),这种切换一秒发生几百次,CPU 毫无压力。
但在 AI 智算集群(如 400G 无损网络、百万 IOPS 的 Weka 存储、8 卡 GPU 疯狂同步)场景下,这种切换成了噩梦:
- 每次“用户态 $\leftrightarrow$ 内核态”的切换,CPU 都要做:保存现场 $\rightarrow$ 刷掉 CPU 缓存(TLB/Cache) $\rightarrow$ 权限提升 $\rightarrow$ 内核干活 $\rightarrow$ 数据拷贝 $\rightarrow$ 降级返回。
- 如果每秒有 1000 万个网络包(Mpps)进来,CPU 光是用来做这种切换(上下文切换税 / Context Switch Tax),利用率就会直接飚到 100%,而分配给大模型训练的算力就会被严重剥夺。
💡 这正是我们前面提到所有黑科技的诞生原因:
- DPDK:直接把网卡驱动拉到 用户态 (Ring 3)。网卡收到包直接 DMA 到 PyTorch 的用户内存里,免去内核态切换,零拷贝。
- SPDK:直接把固态硬盘驱动拉到 用户态 (Ring 3)。CPU 驻留用户态直接轮询 SSD,免去读盘时的系统调用和中断。
- GPUDirect (GDR/GDS):更狠,不仅免去内核态,甚至连 CPU 都不要了。网卡和 SSD 直接和 GPU 的显存(HBM)面对面通信,完全实现零 CPU 参与。
现在,你是不是彻底明白为什么在优化 AI 算力时,SRE 和 Infra 架构师们总是想尽一切办法要去“旁路内核 (Kernel Bypass)”,让数据死死留在“用户态”或“硬件层”了吧?
