Linux内存管理 - 云栖梦泽

[linux内存管理] 第000篇 Linux内存管理系列开篇

系列深入剖析Linux内存管理在ARM64架构下的原理与实现，覆盖物理内存初始化流程、核心分配器机制（如buddy、slab、vmalloc、CMA等）、缺页异常处理、页面回收、内存节点解析等关键环节，结合Kernel 5.15源码与丰富补充资料，帮助读者系统理解底层架构与内存管理优化要点

[linux内存管理] 第 058 篇从虚拟内存到 Swap —— 交换子系统整体架构

本文阐述了Linux交换（Swap）子系统的核心作用与架构。其核心观点是：Swap的根本意义并非简单地用磁盘空间扩展内存，而是为那些本身没有持久后备存储的“匿名页”（如堆、栈数据）提供一个临时的后援存储。当物理内存紧张时，系统可以将这些匿名页换出到Swap空间，从而腾出物理内存供更急需的进程使用，这是Linux内存回收机制的关键一环。而有文件后援的“文件页”则可直接丢弃，需要时再从文件重新读入。

[linux内存管理] 第 057 篇 OOM Kill 与 panic_on_oom —— 杀人的艺术与崩溃的抉择

本文深入解析Linux内核OOM（内存不足）处理机制的最终环节。核心内容包括：通过`oom_kill_process`函数处决选定的受害进程（victim），其流程涵盖检查进程退出状态、打印系统内存日志、处理cgroup组，并最终发送SIGKILL信号。同时，文章阐释了`panic_on_oom`参数的不同取值（0、1、2）如何决定系统在OOM时是终止进程还是触发内核崩溃，为系统管理员在稳定性与故障恢复间提供了关键的选择依据。

[linux内存管理] 第 056 篇 OOM Reaper：异步解除映射的幕后英雄

OOM Reaper是Linux内核为解决OOM kill后内存释放延迟问题而设计的异步清理机制。当进程被OOM killer选中后，可能因自身处于不可中断状态而无法及时释放内存。OOM Reaper通过独立的内核线程异步扫描并回收受害进程的页表和物理页，避免系统因等待进程退出而陷入僵局，确保内存能快速回收，有效防止了OOM场景下的系统饥饿。

[linux内存管理] 第 055 篇 OOM Killer 死亡名单算法

OOM Killer是Linux系统在内存耗尽时选择进程终止的机制。其核心算法oom_badness()通过三道过滤（排除init进程和内核线程、检查cpuset、排除正在终止的进程）和一个打分过程，为所有可终止进程计算“死亡分数”。分数基于进程的RSS、页面交换使用量等内存占用指标，最终选择最高分的进程作为牺牲者，以最大化释放内存并最小化系统影响。该设计体现了在极端内存压力下的平衡策略与工程智慧。

[linux内存管理] 第 054 篇 OOM触发 + Memory Reserve + out_of_memory 决策

本文深入解析Linux内存管理中OOM（内存溢出）的触发机制与决策流程。文章聚焦于从内存分配失败到系统响应的关键链路，涵盖OOM触发的三条路径、作为最后防线的Memory Reserve（32页保留内存）机制，以及out_of_memory()全局入口的决策内幕。通过对核心数据结构oom_control及具体调用链的分析，揭示了内核在内存耗尽时如何从回收自救逐步走向进程查杀的全过程。

[linux内存管理] 第 053 篇 OOM 整体流程：从内存耗尽到系统崩溃的完整链路

本文详细解析了Linux内核中OOM（内存不足）机制的完整处理流程。当系统内存耗尽且所有回收手段（如直接回收、kswapd、内存规整）均告失败后，内核会触发OOM处理。文章介绍了OOM的定位（回收失败后的最终策略）及其主要触发场景，包括全局内存不足和cgroup（memcg）内存限制等。核心在于系统必须决定是否终止进程、选择哪个进程作为牺牲者，以及在极端情况下是否触发系统恐慌。

[linux内存管理] 第 052 篇 shrink_page_list：内存回收的“最后一道关口”

shrink_page_list 是 Linux 内核内存回收机制的最终执行层。它负责从 LRU 链表取出待回收页面，并逐个做出“回收”或“保留”的判决，将决定回收的页面真正释放到伙伴系统。该函数位于整个回收调用链的末端，是内存释放的实际操作者，其决策过程包含了页面锁、访问引用、脏页写回等多项关键检查。

[linux内存管理] 第 051 篇内存回收核心 shrink_node

shrink_node 是 Linux 内存回收路径的核心枢纽：无论是 kswapd 后台回收，还是 direct reclaim / node_reclaim 这种前台、同步回收，最终都汇聚到这个函数，在节点维度完成真实的页面回收调度。文中用结构化示意图清晰展开 shrink_node 的调用链：上游由 kswapd_shrink_node（后台回收）、shrink_zones（try_to_free_pages 路径的 direct reclaim）以及 __node_reclaim（快速 node_reclaim 同步回收）等入口触发；下游则分流到 shrink_node_memcgs、

2026 年 9 月
日	一	二	三	四	五	六
		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	26
27	28	29	30