2025 年的最后一版内核发布后我照例把这一整年追的 changelog、邮件列表讨论和生产环境改配置的记录翻出来做了一次盘点。Linux 内核这一年没有特别抓眼球的版本号大事件但真要细看值得说的内容一点不少调度器默认行为变了、Rust 在核心子系统里越站越稳、存储和虚拟化的性能路径被重新梳理了一遍甚至长期只存在于打补丁阶段的实时抢占也正式进入主线。这篇文章不是通读 commit 之后的流水账而是我筛出来的“十大技术创新”年终盘点。筛选标准有三个是不是已经在主线站稳、是不是直接影响生产负载、是不是能让你在明年升级内核或写驱动时少走弯路。每条我都会尽量说清楚它解决的问题、底层的原理以及我实测或踩坑后的具体建议这样你看完不光是知道“有个新功能”而是清楚“我该怎么用”。1. 盘点先交代标准免得十大变成“十热”每年到了年尾各种“年度十大”都容易变成热搜词合集谁声音大谁上榜。这次我把范围严格限定在 Linux 内核本身只统计那些已经合入主线或明确进入主线开发路径的技术不把发行版的新装界面算进去。具体我按四条线去筛调度与实时性、存储与 I/O、安全与虚拟化、显示与嵌入式。每条线挑两到三个真正改变了开发或运维方式的点最后凑成下面这个列表Rust 进入更多核心子系统从“驱动玩具”变成基础能力EEVDF 调度器从新默认变成可调优的默认PREEMPT_RT 主线化嵌入式与工业场景直接受益io_uring 成为高性能数据通路的事实标准BCacheFS 从实验文件系统走向生产级选择KVM 虚拟化能力升级跨系统共享文件更顺畅硬件辅助内存安全特性真正落地可再现构建与内核工具链升级DRM/KMS 显示协议栈持续演进嵌入式内核在功耗、散热和资源受限场景的优化下面从第一项开始拆每一项都会给出“为什么重要 原理 实操建议”三层内容。你可以把它当成一份年度技术报告也可以当成 2026 年选内核版本的决策参考。2. 调度、实时性与语言安全内核地基的三大变化2.1 Rust 进入更多核心子系统而不是只做驱动Rust for Linux 在几年前的版本里合入时很多人的印象还停留在“能编译模块、能写一个 hello world 驱动”。到了 2025 年这个局面已经明显变了。Rust 的使用范围不再限于外围驱动而是开始向虚拟文件系统钩子、网络过滤路径、固件接口等关键位置渗透。为什么这是个大事件因为内核里相当比例的 CVE 都来自内存安全问题比如释放后使用、缓冲区越界、空指针解引用。Rust 通过所有权和借用检查把这类问题在编译期就拦掉了大部分。内核选择在最容易被攻击的边界层引入 Rust不是因为它比 C“更潮”而是因为这些地方出了问题代价是整台机器被打穿。我自己的体会是Rust 进内核这件事最大的影响其实在构建方式上。以前编内核只要把 GCC 装好就行现在如果你开的配置里有 Rust 模块工具链要求就变了。建议在干净环境里先跑一次检查rustup toolchain install stable rustup component add rust-src make LLVM1 rustavailable make LLVM1 defconfig make LLVM1 -j$(nproc)实测下来Rust 对最终内核镜像大小和启动时间的影响很小真正肉眼可见的代价是构建时间会变长。所以我的建议是普通服务器场景不用刻意追求开启所有 Rust 驱动按发行版默认就好但如果你自己维护边缘设备或安全要求高的网关可以主动把 Rust 驱动开起来长期看比修 CVE 的运维成本划算得多。2.2 EEVDF 调度器从“新默认”变成“可调优的默认”EEVDFEarliest Eligible Virtual Deadline First调度器从引入到成为默认经历了好几个大版本的磨合。2025 年大家已经不太讨论“要不要切回去”而是开始研究怎么针对业务做调优。这算是调度器真正成熟的标志。EEVDF 和 CFS 最核心的差别在于对“任务延迟”的建模方式。CFS 尽量让每个任务公平分配到 CPU 时间EEVDF 则把任务的“虚拟截止时间”作为选择依据配合 lag 的概念让新唤醒的任务能更快拿到 CPU同时避免长期饥饿。这样做的效果是交互式任务和延迟敏感型任务的唤醒延迟更可预测高并发下不容易出现某个突发请求被拖到队尾的情况。如果你跑的是 Web 网关或消息队列这个变化通常体感不明显因为默认配置已经省心。但如果你想压榨性能就需要主动控制任务的优先级和延迟权重。传统做法是用 nice 调优先级EEVDF 时代更推荐配合sched_setattr接口设置sched_latency_nice低 latency-nice 值的任务会被优先唤醒。一个我常给团队分享的排查思路升级内核后如果发现某些短任务延迟变大先别急着骂调度器回归大概率是默认行为变了需要你显式给延迟敏感任务调低 latency-nice。可以在启动脚本里用工具设置或者直接通过 cgroup v2 的cpu.weight做组间配额。把这两层理解清楚后EEVDF 就不再是黑盒而是一个可以按业务微调的参数系统。2.3 PREEMPT_RT 主线化嵌入式与工业场景直接受益PREEMPT_RT 是 Linux 社区折腾了十几年的实时抢占补丁集终于在最近几个大版本里正式进入主线成为可配置的内核特性。2025 年我们谈的不再是“找第三方补丁编译实时内核”而是直接开配置项CONFIG_PREEMPT_RTy然后得到一个官方维护带实时的内核。这对工业控制、机器人、音频处理、车载系统的意义是巨大的。以前“实时 Linux”意味着你要维护一套带外补丁的内核升级周期长出问题也没人管。现在主线支持后嵌入式开发者可以把精力放回业务逻辑。当然配置只是第一步真正的实时性还需要配合 CPU 隔离与中断处理调整。我给做嵌入式项目的朋友推荐的内核启动参数是isolcpus2,3 nohz_full2,3 rcu_nocbs2,3这个组合的意思是把 CPU 2、3 从通用调度中隔离出来关掉时钟节拍并把 RCU 回调挪走让它们专门跑实时线程。然后配合线程优先级设置把关键任务的SCHED_FIFO优先级提到 80 以上。这里有个很容易踩的坑光开 PREEMPT_RT 和隔离但关键线程不用实时优先级效果和普通内核差别不大。实时不是开关而是一整套配合动作。3. 存储与 I/Oio_uring、BCacheFS 与能效优化3.1 io_uring 从异步 I/O 框架变成高性能数据通路事实标准io_uring 出来好几年了但 2025 年它才真正变成“高吞吐服务默认考虑”的组件。不是因为它突然出现了革命性新特性而是因为生态跟上了数据库、缓存层、代理、对象存储都有了比较成熟的 io_uring 接入方案甚至网络协议栈里也能看到 io_uring 做零拷贝收发。它的核心原理值得再强调一遍传统 read/write 每次都要进内核、切上下文、拷贝数据io_uring 则通过内核和用户空间共享的环形缓冲区提交请求和收割结果一套 SQ/CQ 机制把系统调用开销降到接近零。对每秒几万次小 I/O 的服务收益非常明显。我建议有自研网络服务或存储客户端的团队今年重点验证三个 io_uring 场景固定文件IORING_REGISTER_FILES、固定缓冲区IORING_REGISTER_BUFFERS、以及 multishot receive。前两个能减少文件描述符和内存映射的查找成本第三个能让你在无需重新提交的情况下持续接收网络包。不过需要泼一盆冷水io_uring 不是万金油。对小文件随机读或者任务本身阻塞在业务逻辑上的场景可能比传统 epoll 更复杂收益却不高。我见过有人为了用 io_uring 把整个架构改复杂最后性能还掉了。正确姿势是先找出瓶颈确实在系统调用和内核路径再引入 io_uring不要为技术而技术。3.2 BCacheFS 从实验文件系统走向生产级选择文件系统领域的创新向来保守因为数据安全兜底太重要了。2025 年 BCacheFS 终于从“另一个实验性文件系统”变成了“可以在部分场景认真评估的生产级选择”。BCacheFS 最大的卖点是它把 cache、RAID、快照、校验和、压缩做进了一个文件系统里。以前你要用 bcache 做缓存加速、用 mdadm 做 RAID、用 LVM 做快照三个工具三套配置BCacheFS 把这些整合成一套命令。对大量读多写少、又不想维护复杂存储栈的场景这是很实际的省心方案。创建和使用很简单mkfs.bcachefs -f /dev/sdb /dev/sdc --replicas2 mount -t bcachefs /dev/sdb:/dev/sdc /mnt/bcachefs--replicas2会在两块盘上做镜像等价于 RAID1省掉了 mdadm 的环节。但我必须负责任地提醒任何新文件系统都别急着当唯一副本。我的建议是先在备份良好的环境跑三个月重点观察磁盘故障恢复、掉电后的 fsck 行为、以及升级兼容性。BCacheFS 的设计激进、维护者响应也快但“可用”和“用了十年”的成熟度还是有差距。如果追求极致稳定ext4/xfs 仍然是默认选择如果你愿意用时间换新功能集成度BCacheFS 值得上测试机。3.3 内核在功耗与散热调度上的持续优化2025 年数据中心电费和散热成本被反复讨论内核也随之把更多注意力放到能效上。这一年的变化不是单点突破而是 cpufreq、cpuidle、调度器三者的配合越来越精细。最典型的是 EASEnergy-Aware Scheduling在大小核架构上的成熟。当负载不高时调度器会把任务优先放在能效核上负载上来后再把任务迁移到性能核并动态调频。这听起来简单实际上背后涉及功耗模型、任务迁移代价、延迟容忍度等一堆 trade-off。内核把这套机制铺得越稳厂商就不需要自己做太多 hack。运维层最容易感知到的是 “turbo 频率维持时间” 和 “空闲状态进入率”。如果你想观察自己的机器到底省没省电可以用turbostat看实际运行频率、用powertop看唤醒原因。一个重要经验能效优化有时会伤害尾部延迟。如果业务对延迟极敏感建议把关键服务钉在性能核上不要让它被 EAS 迁来迁去。也就是说能效是趋势但不是所有场景都该一刀切地“节能优先”。4. 安全、虚拟化与供应链可信度4.1 KVM 虚拟化能力升级跨系统共享文件更顺畅虚拟化方向的年度关键词是“减少损耗”和“安全隔离”。KVM 这一年重点优化了虚拟中断投递、内存保护与热迁移路径。在大规模云环境下vCPU 调度、虚拟设备队列和内存后台回收的改进让虚拟机跑密集计算时更接近裸机性能。对普通开发者和测试人员来说体感最明显的是跨系统共享文件这一块。“Windows 与 Linux 共享文件”是长期热点问题。传统方案里SMB 和 9p 都能用但性能经常差强人意。2025 年更多平台把 virtiofs 当成了首选的共享文件方案。它的原理是把宿主机的文件系统直接暴露给虚拟机绕过了逐层封装的网络文件协议读写性能比 9p 高出一个量级。QEMU 场景下启用 virtiofs 的基本思路是这样的宿主机启动一个 virtiofsd 守护进程然后把目录通过 vhost-user 传给虚拟机。配置里大致会涉及qemu-system-x86_64 ... \ -chardev socket,idchar0,path/tmp/virtfsd.sock \ -device vhost-user-fs-pci,queue-size1024,chardevchar0,tagshared \ -object memory-backend-memfd,idmem,size8G,shareon \ -machine memory-backendmem注意shareon这步不能漏因为 virtiofs 需要共享内存才能做零拷贝。如果你只是在局域网里跨两台物理机共享那还是 SMB 或 NFS 更合适别把 virtiofs 用错场景。4.2 硬件辅助内存安全特性开始真正落地这几年 CPU 厂商往芯片里塞了不少安全特性但硬件有了内核不用也是白搭。2025 年是这些硬件特性真正在内核里落地的年份ARM 的 MTEMemory Tagging Extension、x86 的 Shadow Stack 和 Pointer Authentication都逐渐进入了内核的正常构建选项。MTE 的思路很直观给每次内存访问盖一个 4bit 的标签指针和内存本身都要匹配访问时不匹配就立即报错。这样一来越界访问和释放后使用会被硬件直接抓出来而不是在几毫秒后变成诡异崩溃或数据损坏。x86 的 Shadow Stack 则是用来防 ROP 攻击的它维护一个只读的返回地址栈如果返回地址被篡改硬件立刻触发异常。对生产环境的建议是如果你的服务器 CPU 够新、发行版支持对应配置可以主动打开这些特性。它们会带来几个百分点的性能开销但在安全敏感场景这个代价可以接受。开这些特性前先用工具确认硬件支持别在旧机器上凭空期待效果。还要注意这类特性通常要求“内核 用户态程序 编译器”三方配合只升级内核是不够的。4.3 可再现构建与开发工具链升级供应链安全不只是看签名还要解决“你拿到的二进制到底是不是这份源码编出来的”。可再现构建是今年的重要进展理论上同一份源码、同一套工具链、同样的时间戳任何时候构建得到的二进制哈希都应该一致。内核社区一直在压缩构建过程中的不确定因素比如默认时间戳、随机生成的头文件、压缩包里的排序差异。对于维护者来说这意味着可以更快验证第三方发行版的二进制是否被篡改过。我自己也验证过一次完整的可再现构建流程大概是设置固定的KBUILD_BUILD_TIMESTAMP统一编译器版本然后连续构建两遍做哈希对比。这过程看着简单实际上任何一点环境污染都会导致哈希不一致排查起来很磨人。工具链层面Clang 在内核构建中的占比越来越高带来的直接好处是静态分析和报错信息比老 GCC 路径更清晰。不少团队开始默认用make LLVM1构建配合bear或内核自带的gen_compile_commands.py生成 compile_commands.json让 IDE 精确跳转。这种变化对普通开发者的体验提升是实实在在的读源码不再靠 CtrlF 碰运气了。5. 显示、嵌入式与源码阅读体验5.1 DRM/KMS 显示协议栈持续演进桌面与嵌入式都受益显示子系统在 Linux 里的核心一直是 DRM 和 KMS。DRMDirect Rendering Manager管显存、提交和渲染上下文KMSKernel Mode Setting管显示模式、分辨率、连接器状态。2025 年DRM/KMS 在 HDR、自适应刷新率、更好支持新一代显卡方面都有进展桌面 Linux 用起来越来越像“正经操作系统”。这里有一个常见但总被误解的层级关系。很多人在 Qt 或 GTK 程序遇到显示问题时会看到这么一条链路屏幕硬件 → DRM 内核 → X server(Xorg) → X11 协议 → Qt(xcb插件) → 你的Qt应用理解这条链路很重要。xcb 插件只负责让 Qt 应用跟 X server 对话X server 再通过 DRM 控制显示硬件。如果应用界面异常不一定是 Qt 的问题也可能是 X server 或驱动层的问题。排查时用dmesg看 DRM 日志、用glxinfo看 OpenGL 信息、用xrandr看显示模式逐层定位。如果你的应用跑在嵌入式平台没有 X serverQt 有直接走 DRM/KMS 的插件也可以只用 EGLFS 或 Wayland 后端。我的建议是新项目直接拥抱 Wayland 和 XWayland 兼容这套组合在性能和多显示器处理上比老 X11 体验好很多但遇到老设备时了解 xcb 和 X11 的链路仍然能帮你快速判断问题。5.2 嵌入式内核源码与资源受限设备的优化嵌入式 Linux 依然是内核生态里最活跃的领域之一因为设备形态多每个项目都是定制活。2025 年的明显趋势是资源受限设备不仅要能跑还要跑得稳、启动快、功耗低。内核为此提供了一系列能力可以减少启动阶段不需要的驱动、用设备树Device Tree裁剪硬件描述、通过 cgroup v2 限制进程内存、用 BPF 做轻量级追踪。对 128MB 内存的小设备内存管理的改进尤其重要zram 配合 zswap 能显著提高可用内存。我在调试嵌入式内核时通常会做这样一轮操作先用menuconfig收缩不需要的文件系统和驱动再把代码段、数据段、栈都放到合适的位置最后通过perf或 ftrace 找出启动路径上的“大头”——很多时候瓶颈是某个驱动长时间等待 probe。嵌入式内核源码学习最好的入口就是这份裁剪和启动优化过程你把每一个CONFIG_选项关掉或打开时都能直观看到镜像大小和启动时间的变化这种反馈对理解内核很有帮助。5.3 用 CLANGD 打开内核源码零基础也能顺手读代码很长一段时间里看内核源码都靠传统编辑器加 tags跳转原理全靠脑补。2025 年我觉得“内核源码阅读”这件事的体验已经被工具链彻底刷新了。现在用 VS Code 结合 clangd几乎可以做到看一个大型 C 项目一样舒服定义跳转、引用查找、自动补全、语法检查全部基于真实编译参数。具体步骤如下适合想从头读内核源码的朋友make LLVM1 defconfig make LLVM1 -j$(nproc) scripts/clang-tools/gen_compile_commands.py第一条命令生成默认配置第二条构建内核这一步需要点时间第三条生成compile_commands.json。然后在 VS Code 里安装 clangd 插件让它读取这个文件即可。这样你打开kernel/sched/fair.c或者fs/io_uring.c跳转和查找都会非常准确。我拿这个方法带过几个刚学内核的同事效果比让他们直接盯着邮件列表讨论好太多了。代码能跳转、报错能定位学习曲线一下就缓下来了。如果你不想用 VS CodeNeovim 配 clangd 也有同样效果。6. 年度实操问题排查与避坑记录6.1 PCIe BAR 资源分配失败怎么处理今年被问得最多的问题之一是启动日志里出现“Linux 内核无法给 PCIe 桥接器分配足够的内存映射空间即 BAR 地址”。先解释背景PCIe 设备需要一段物理地址空间来映射寄存器这个空间叫 BAR。桥接器则负责把下游设备的 BAR 窗囗映射进 CPU 地址空间。如果你插了多张大卡或 NVMe 硬盘BIOS 预留资源不够内核就会报这类错误。我建议按这个顺序排查。先用lspci -vvv看设备树的资源占用再用dmesg | grep -i BAR|bridge看看具体失败点如果确认是资源不够进入 BIOS 开启 “Above 4G Decoding” 和 “Resizable BAR”这类选项能让内核利用 64 位地址空间有效缓解 32 位地址资源不足的问题。对于服务器尽量把大设备插在不同 CPU 直连的 PCIe 根端口上不要让它们挤同一条桥下链路。还有一个老参数可以用在内核命令行里加pcirealloc让内核在启动时重新分配 BAR。这个参数解决了不少主板上资源分配不合理的问题但要注意某些老设备对重分配兼容性差改了之后最好用lspci确认每个设备都能正常枚举。6.2 Windows 与 Linux 共享文件慢常见解法“Windows 与 Linux 共享文件”的需求常年排在前列但很多人一上来就用默认方式挂载然后抱怨速度不行。如果你是在局域网里让 Windows 和 Linux 物理机互通首选 SMB 3.1.1 挂载并且打开 multichannel 和 loose 缓存mount -t cifs //192.168.1.10/shared /mnt/share \ -o usernameuser,passwordpass,vers3.1.1,multichannel,cacheloosemultichannel能同时利用多网卡或多次 TCP 连接提升吞吐cacheloose减少读请求的往返次数。如果是虚拟机场景别再纠结 SMB直接切 virtiofs。如果一个方案试了 10 分钟性能还上不去先检查网络链路本身再怀疑协议。6.3 升级内核后延迟抖动先从调度和电源找原因每年都会有人遇到“升级内核后延迟变高”的问题今年 EEVDF 和 EAS 成熟后这类问题更容易出现。我的排查顺序很固定先看 CPU 频率是否频繁跳动cpupower frequency-info检查 governor再看任务是否被 EAS 迁移到能效核通过perf sched latency看调度延迟最后看 cgroup 的 cpu 限额有没有限制突发。如果延迟敏感业务受到明显影响可以先用chrt给关键线程设置实时优先级或者在 cgroup v2 里单独建一个cpu.weight更高的分组。要注意新内核默认参数不一定照顾旧业务的习惯调整后必须用压测数据说话别凭感觉调完就撒手。6.4 多 GPU 并发测试的 DRM 设备冲突多 GPU 同时测试也是高频场景比如三张卡一起跑模型推理或渲染。最常见的坑是程序默认跑到了不期望的卡上或者设备节点被应用占用出现 “DRM device is busy” 之类的错误。先摸清设备lspci | grep -i VGA\|3D ls -l /dev/dri/by-path/然后通过环境变量指定 GPU。DRM 场景里用DRI_PRIME1选择第二张卡CUDA 场景里用CUDA_VISIBLE_DEVICES0,1,2控制可见卡。如果你在做训练或渲染集群建议给每张卡分配独立用户或 cgroup避免一个应用把/dev/dri/card0长期占用导致其他任务拿不到设备。7. 最后再分享几点新年学习建议十项技术逐条说完了有些朋友可能觉得“内核太远跟我的日常工作没关系”。其实不存在完全无关这回事。你用的发行版、你跑的容器运行时、你调过的数据库缓存底下全是这套内核逻辑。如果 2026 年你想认真提升一下内核能力我建议从三条线入手。第一把 EEVDF 和 cgroup v2 的 CPU 控制关系搞清楚这能解决很多莫名其妙的性能问题。第二学会用 ftrace 或 perf 看一次真实的系统调用路径很多概念看着抽象但当你亲眼看到openat在日志里跑了一遍理解深度完全不同。第三用 clangd 把内核源码真正打开每天只看一个函数坚持三个月你就发现内核没那么神秘了。我过去一年最大的体会是内核学习的曲线不在于“读不懂源码”而在于没找到从代码到实际行为的连接点。一旦你能把一个内核参数和仪表盘上的延迟曲线对应起来知识就开始滚雪球了。希望这份盘点能给你提供一些可落地的线索也欢迎在评论区聊聊你今年在 Linux 内核上最值得的项目经历。
