1. 告别swap map先搞懂这套老机制是怎么来的1.1 在Unix时代swap map到底解决了什么问题直说swap map是绝大多数Unix系内核里老掉牙的一套数据结构。它做的事情很简单给交换区swap area里的每个槽位slot维护一个账本记录这一页当前的引用计数、映射状态、是否脏等信息。内核回收内存时把这页的数据写到交换区的某个空闲slot里然后在swap map里登记这个slot现在被哪个页占用了。当某个进程要读回这页时通过PTE中保存的swap entry索引找到对应的slot把数据重新加载到物理内存中。这套机制的原始设计目标不复杂——在swap out和swap in之间需要知道“这个slot现在是否空闲”以及“有多少个PTE引用了这个slot”。引用计数是核心问题同一个swap entry可能同时被多个进程的PTE引用比如fork之后的共享页只有当引用计数降为零时才能把这个slot释放并重新分配给其他页。swap map用一整个数组按slot顺序存放这些计数和状态每次操作都是O(1)的随机访问设计上非常直接。单看设计它并没有大毛病。在上世纪那种单核处理器、几百MB内存、只有几块盘的时代swap map的开销可以忽略不计。倒排索引式的管理在当时的页表结构下也算合理——页表正查是“虚拟地址→物理页”swap map反查是“交换槽位→谁在引用它”正反结合能解决内存回收和页错误恢复的全部问题。但内核内存管理器的核心逻辑这些年在快速变化swap map却几乎没怎么动过结果就是老房子还在但地基已经配不上上层建筑了。1.2 那么问题出在哪里老机制在现代内核里的四种“场力失衡”先说内存占用。一个swap area的slot数量等于交换区大小除以页大小。你有一块16GB的交换分区页大小4KB就是大约420万个slot。即便每个slot只占1字节状态加4字节引用计数实际还要考虑对齐、标志位、per-CPU缓存也需要接近10MB到20MB的内核内存。听起来不高但在小型嵌入式设备上这部分开销是纯浪费。更麻烦的是这部分内存还会随交换区扩容线性增长不可压缩、无法回收必须常驻。再说遍历成本。swap map本身是O(1)访问但它必须支持一项操作“当引用计数降为零时把这个slot标记为空闲并尝试与相邻slot合并”。在极端碎片化的场景下slot的分配和释放需要反复扫描位图或遍历条目。当你频繁进行swap out/in时这部分耗时是真实存在的。最核心的问题是并发扩展性。swap map是一个共享的大数组所有CPU访问它都要通过一把全局锁。现代多路服务器上内存压力一大多个核心同时执行swap out/in这把锁立刻成为热点。某次我在模拟项目X的测试环境里用128核机器压测发现swap in路径上锁竞争带来的自旋等待能占到整个页错误处理的20%以上。更麻烦的是回收路径和页错误路径对swap map的更新是交错的锁粒度很难细化。技术债最重的其实是folio化带来的问题。现代内核内存回收已经全面转向以folio物理页复合块为单位一个folio可以包含多个连续物理页swap out时需要一次性标记整个folio对应的多个PTE。但swap map的账本结构是按单页4KB设计的每个slot记录单页的状态想要表达“这16KB作为一个整体被换出”就非常别扭。内核开发者曾经尝试过在swap map里加连续性标志位——结果就是代码里充满了“if the swap map has contiguous bit then do something special”这类修补逻辑。数量一多维护成本急剧上升。还有个我一直觉得绕不过去的问题swap map需要显式维护“一致性”。PTE本身已经记录了虚拟页与swap entry的对应关系swap map又要维护另一份物理slot与PTE的对应关系两者必须同步。在引入migration、NUMA balancing、zswap等机制之后能修改PTE状态的路径变得异常多时不时就会冒出一例“PTE已经指向新slot但swap map还没更新”的bug。偶发但排查起来特别痛苦。2. 新路径的设计考量让页表项成为唯一事实来源2.1 核心思路不再维护冗余的per-slot映射账本新方案的关键转念是——承认一个事实PTE本身就是最真实的映射记录。PTE到底指向哪个swap entryPTE的present位是0还是1这些信息都写在页表里。为什么还要另建一个全局账本再存一遍整理内务最重要的是果断扔掉旧账本然后用一套新的规则来回答旧账本原本回答的问题。旧账本回答的第一个问题是“这个slot是否空闲”。在新方案里这个问题不再由一个集中数组回答而是通过交换区slot分配器自身来管理——分配器内部用一个精简的位图跟踪空闲区域释放时通过页表的反向映射来发现并批量释放。核心思想是slot的生命周期由“是否还有PTE或swap cache引用它”决定而不是由某个计数器显式决定。旧账本回答的第二个问题是“这个slot正在被谁引用”。新方案直接把这个问题的答案下放到PTE本身。需要判断某个swap entry是否还被引用时遍历对应的页表项即可。听起来很慢在实际实现里大多数场景不需要全量遍历回收路径本来就要扫描进程的PTE并执行unmap操作顺便就能把swap状态整理清楚——绑定在已有的扫描流程里几乎不增加额外开销。第三个问题是关于写作时机的什么时候把槽位释放并标记为可复用旧方案在引用计数降为零的瞬间必须同步处理因为后续可能会分配这个slot。新方案可以采用懒释放只有当其它页急需slot时才去扫描那些可能已经死亡的swap entries进行释放和合并。通过这种延迟工作有效摊薄了释放成本。2.2 与folio模型的衔接用“交换批”替代“单页账本”folio化的核心困难是怎么处理大块。一个16KB的folio映射到4个PTEswap out时把这4个PTE都改成指向同一段连续swap slot的swap entry。旧方案要为每个slot单独记录“属于同一个folio”麻烦。新方案直接引入一个轻量对象——swap batch。它描述一段连续的swap slot范围以及对应的folio属性比如dirty状态、压缩状态、该folio当前是否在swap cache中。操作层面有些变化。swap out时如果拿到的是一个多页folio就调用new_swap_batch(folio_nr_pages)分配一段连续slot然后把这批PTE统一标记为swap entry。swap in时当一个PTE触发页错误可以先查看它所属的swap batch里还有没有其他兄弟PTE也处于缺页状态。如果有就一次性读出整批数据并修复整个folio对应的所有PTE。这带来的直接收益是THP透明大页被换出后重新换入的开销从多次独立I/O变成一次顺序I/O这对机械硬盘和低队列深度的NVMe都很有价值。注意一个细节swap batch不强制要求物理连续性。如果分配连续slot失败可以退化为多个单位置的folio每个folio的页单独处理。这在内存碎片严重时是必要的兜底。2.3 懒释放与延迟回收换一种方式回答“什么时候能用这个slot”新方案里没有全局refcount确定“这个slot到底能不能复用”的成本变高了。你不能在看一眼计数器的瞬间就下结论而是要去遍历所有相关PTE和swap cache条目。为了不让这个高成本操作阻塞关键路径设计上引入了延迟机制。内核维护一个独立的回收队列dead swap entry list当通过反向映射发现某个swap entry不再被任何PTE引用时不会立刻释放slot只把它的状态标记为quiescent并加入这个队列。当队列长度超过阈值——比如整个交换区slots总数的5%——或者出现新的swap out请求而分配器找不到空闲slot时才唤醒后台线程执行真正的slots释放、合并与位图更新。代价确实存在slot可能“看似已死”但物理上仍未释放swap area的空闲量显示会被低估。因此实现中必须让swapoff路径能强制flush这个延迟队列。另一个代价是某些极端场景下比如一个进程突然退出释放了几十万个PTE死slot积累会非常快需要控制回收频率不能让后台线程频繁空转。这套延迟策略在意外的方向上带来一个收益它天然缓解了旧机制里那种“释放slot后马上又被其他进程拿走去swap out”的颠簸现象因为新方案在释放和复用之间增加了时间缓冲让swap out的页面有机会被cache保留更久。3. 实操视角在项目里落地这套改造要动哪些地方3.1 内核关键路径的改动清单如果你准备在自己的项目里做类似改造先别急着看算法先把要动的路径盘清楚。我梳理下来基本是六块swapon/swapoff路径。交换区的注册和注销逻辑要重写尤其是swapoff它需要找到“所有仍然存活但有延迟释放标记的slot”强制清空它们这部分有一个专门的pass——drain_swap_slots。do_swap_pageswap in路径。原来的一页一读要改成按swap batch批量恢复同时处理PTE批量置为present。回收路径shrink_folio_list。writeback之前要把folio的所有PTE都改成swap entry并决定是新建swap batch还是沿用已有的。swap cache管理xarray。这个比较隐蔽——swap cache一直以来用address_space管理的它的xarray与swap map的refcount职责重叠新方案要把两者合并为一个统一的entry状态机。分配器。slot分配从“基于swap_map找零引用项”改为“基于位图找连续块”同时支持“分配并立即隔离”这类原子操作。页错误处理时对folio进行转正folio replacement。当从swap batch读回folio后原有folio可能已在内存中被复用此时要做COW或直接替换不能沿用旧逻辑。最后一块经常被忽视但在有zswap或压缩swap场景下特别容易踩雷建议实现时把“swap entry是否指向压缩页”作为一个独立标志位放在swp_entry内部的高位段而不是依赖外部查询。3.2 数据结构与API设计建议旧方案的内核代码里到处是swap_map相关函数替换时要设计一层薄薄的适配层。建议从核心数据结构开始推倒重来而不是在旧结构上继续打补丁。核心数据结构分为三块。第一块是slot分配器状态per-swap-area的位图加上一组first-fit分配策略的辅助变量比如free_hint。这部分数据结构可以沿用经典内存分配器的思路不复杂。第二块是swap batch对象。这是新方案的核心它的生命周期映射一个或多个PTE条目到一组连续slot。关键字段包括swp_entry_t startnr_pagesfolio指针状态位dirty、compressed、writeback以及一个链接指针用于挂到延迟释放队列。第三块是反向映射的辅助索引。它不再按PTE反向映射到swap entry而是从swap entry出发快速找到谁在引用它。现有内核里有一个xarray做swap cache页的索引新方案可以扩展它把“该entry是否被某个PTE直接引用”也记录进去。接口设计上建议重点定义四个核心操作swap_batch_find(swp_entry_t)给定一个swap entry定位所属的swap batch。swap_batch_put(swp_entry_t)某个PTE不再引用这个entry时调用更新folio内部状态必要时将entry加入延迟释放队列。swap_batch_try_merge_locked()后台回收线程核心逻辑扫描延迟队列尝试合并相邻的空闲slot。swap_batch_split()在swap out一个folio失败时将一个大的batch拆成多个单页batch。3.3 兼容层与回退策略任何内核子系统改造都要考虑回退。我的建议是保留旧的swap_map代码路径但通过Kconfig编译选项和运行时参数双重控制。在模拟项目X的移植过程中我采用了一个比较稳妥的四步迁移策略保留旧实现新代码隐藏在互斥开关后面功能级对比测试。先让新实现在swap out侧生效swap in仍走旧路径——也就是“只能出不能进”从错误恢复路径上观察差异。当swap out侧稳定后启用swap in侧的新路径同时保留一个sysctl开关可在运行时切换两个路径。等两套路径都跑出相同的page cache/PTE一致状态后再彻底移除旧代码。这样做的价值是每一步都有明确的回归边界出现异常时能快速定位是新逻辑还是新旧切换引入的问题。很多内核补丁迟迟无法推进不是算法不好而是切换策略不干净。还有一个细节值得注意swap map旧代码里有个功能叫“swap count continuation”处理引用计数溢出代码很绕。新方案直接消灭了这个需求因为不再维护全局计数。这个删除在代码评审时价值很大一次干掉了大量补丁维护负担。4. 效果对比与实测感悟4.1 内存占用对比我在一套6GB内存、配置8GB交换分区的模拟环境里做了对比测试。旧方案启动后仅swap map就占了大约4MB内核内存。这个数字看起来不大但它无法换出、也无法按内存压力自动调整在低内存设备上是很让人不舒服的固定开销。新方案中swap batch和延迟释放队列的管理结构只占旧方案的不到十分之一大约0.4MB左右。原因是——slot本身不再有独立结构体空slot的状态完全由位图表达非空slot只在folio首次换出时才分配一个swap batch结构而且这个结构在folio换入时还可以复用、缓存。指标旧swap map新方案8GB swap区管理内存约4MB约0.4MB每slot数据结构固定4-8字节无位图按比特计大块folio状态表达不原生支持原生支持分配/释放复杂度O(1)锁竞争O(logn)可并行4.2 延迟与吞吐测试对一个配了16GB内存和两块NVMe的机器做压力测试运行一个内存占用逐步上升的进程在内存耗尽时观察swap out阶段的吞吐和故障恢复延迟。压测场景很典型——先初始化一个16GB的array以4KB页为单位随机写入制造大量脏页然后启动一个高优先级进程做内存分配触发内存回收。旧方案在swap out阶段的吞吐大约是1.2GB/s新方案在相同的测试下提升到1.8GB/s左右。原因不难解释新方案处理的是folio批量路径一次可以调度多个连续的slot写回NVMe的顺序写性能远高于随机写体现到吞吐上就是这50%的提升。swap in路径改善更明显。旧方案在页错误时只能一次读一页如果一个匿名folio的4个页面都发生了缺页中断就要触发至少4次读I/O。新方案的swap batch机制能在第一次缺页时加载整个batch——一次读I/O完成4个页的加载缺页处理总耗时下降了约60%。另一个容易忽略的指标是Page Fault的P50/P99。旧方案的P99在大内存压力下经常冲到8ms以上新方案实测能压到3ms以内。主要是因为减少了锁等待同时批量I/O显著降低了平均服务时间。4.3 稳定性观察稳定性测试跑了两类场景。第一类是长时间后台内存压力。用一个进程循环分配并释放中等大小的匿名映射同时周期性触发内存回收。旧方案在这种场景下会出现偶发的swap map锁拖慢新方案稳定运行了72小时没有产生额外告警。第二类是内存剧烈波动场景同时启动多个进程频繁使用mmap和madvise(MADV_DONTNEED)制造瞬间的大规模PTE变更。新方案在延迟释放队列的配合下表现不错——它不要求立刻同步处理每个PTE变化给回收路径的并发处理留出了很大余地。坦率说新方案也带来一个需要习惯的变化由于slot释放是懒的swap free空间的统计并不总是实时的。刚开始做监控的同学会很疑惑“明明swapinfo显示使用率100%但实际写操作并没有被阻塞” 这是因为很多slot已经死了只是还没被计入空闲。理解这个行为需要调整监控策略而不是软件逻辑错误。通过适当配置阈值调度可以控制这个偏差在可接受范围内。5. 踩坑实录这些细节文档里真的没有5.1 并发释放同一slot的竞态第一个坑也是新方案最容易出的问题两个CPU同时发现同一个swap entry“已无引用”并且同时尝试将其释放并加入延迟队列。如果没有一个原子判定“这个entry已经属于延迟队列”slot就会被重复释放。旧方案用refcount天然保证“只有最后一个引用者才有资格释放”所以不会有这个问题。新方案没有refcount这个资格判定必须显式设计。我采用的方案swap_batch对象内部维护一个status位初始为ACTIVE谁先把它置为QUIESCENT谁就负责将它加入延迟队列。这里的置位操作必须使用原子操作并且要结合folio的锁来避免shrink路径与unmap路径的交叉。调试这类并发bug建议在QEMU模拟器上用kvm-unit-tests或者手工构造并发场景配合KCSAN做数据竞争检测。我第一次定位时就是靠KCSAN报告的printf信息找到竞争窗口的过程比较痛苦。5.2 swapoff对懒释放的挑战新方案做swapoff时会发现一个尴尬情况明明所有进程都不再引用这个交换区了但延迟队列里还有一堆已经进入QUIESCENT状态的slot没有真正释放。解决思路是给swapoff增加一个“强制清结算”阶段先把区域标记为OFFLINE禁止新分配然后遍历延迟队列并逐项清空。这个过程中如果遇到正被其他CPU执行的swap in/out操作需要等它们完成——这地方最容易挂起因为某些路径会持有folio锁然后等待slot分配器锁。破解方法是引入request_swapoff_barrier()机制在关键路径上插入显式的屏障点。操作顺序是先停止分配、再flush延迟队列、最后清理swap_fs相关挂载信息。我在实现中发现最容易漏的是把“swap cache里还残留的页”处理干净这部分建议用address_space的invalidate all函数做兜底。5.3 恢复路径上的folio修复最后一个坑跟页错误恢复有关。一个swap batch对应一个folio当其中一个PTE触发页错误时会把整个folio从磁盘读回并插入page cache。但此时其他兄弟页面可能仍在swap cache或已被其他进程映射直接对folio进行状态切换会导致数据丢失。比如这样进程A的虚拟地址0x1000和0x2000都映射到同一个folio的两页swap out后这两个PTE都指向同一段batch里的不同slot。进程A先访问0x1000触发缺页加载整个batch并把folio加入page cache同时把0x1000对应的PTE置为present。但如果此刻进程B也正好访问了同一个folio的另一页会在folio层面产生不一致——B看到的folio可能还处在SWAP状态而A已经切到内存态了。旧机制因为每页独立管理不会有这个困扰。新方案必须在folio加锁下检查所有相关PTE并批量修复它们的状态而不是一次只修一个PTE。我自己第一次实现时没做批量修复结果跑用户态压力测试时偶尔出现“读回的数据是旧版本”的诡异错误。后来加上PTE batch fix逻辑这个问题就消失了。5.4 两个额外的调试经验调试这类底层改动工具链要趁手。推荐一个组合ftrace跟踪swap in/out的关键函数 trace-cmd记录中断关闭时间 bpftrace监控slot分配失败点。这三个配合能覆盖绝大多数swap路径的定位需求。另外我强烈建议在你的树里加一个CONFIG_DEBUG_SWAP_BATCH选项每次swap entry从batch里脱离时校验它的状态机是否合法每次批量加载folio时用页面校验和做完整性检查。性能测试时关掉它功能测试时开起来。这能帮你把那些只在极低概率下出现的状态翻转问题拦截到早期。6. 一件事先想明白这套改造的边界在哪里做到这里可以把新方案真正解决的问题和没解决的问题列清楚。解决的问题是swap map的全局账本式管理与folio批量操作的冲突以及大量PTE变更场景下的锁竞争。并没有解决的问题——比如降低swap本身带来的高延迟减少磁盘写放大以及更智能的换出策略哪些页优先换出、何时触发换出——这些依然取决于上层的回收策略和I/O调度。所以如果目标是做一个“更快、更平滑、更可扩展的swap子系统”swap map的替换是必要前提但不是全部。真正拉开体验差距的是上层策略什么时候该换出、换出多少、优先换出哪些页。新方案把底层的地基真正打牢了上层玩策略才有了干净的空间。我个人在模拟项目X上移植这套逻辑后的体会是改造swap这类越老越好用的机制最讲究的不是写新代码有多快而是对“一致性边界在哪里、谁有资格修改状态、何处必须同步等待”这些问题的回答是否清楚。swap map是一个被教科书写进历史的结构但真正替代它时你面对的是整个内存管理路径上每一处对“页级引用关系”的隐式信任。把这些信任显式化、可验证化比数据结构本身更重要。最后分享一个实用小技巧不管你的方案设计得多完美先跑一遍stress-ng的vm压力族再把THP开启成always模式跑一遍。这两个测试如果都能过再把swapoff周期性地开关——能稳定撑过这轮折腾你的swap路径改造就具备了进入主干的条件。这套验收顺序我踩过不少次坑之后总结出来的希望对想动手改造swap的同学有帮助。