TLB Shootdown 与 IPI 风暴

• TLB 的 per-CPU 缓存属性
• 页表修改后需跨核失效 TLB
• IPI 风暴与批处理

TLB 是每个 CPU 核私有的页表缓存，当某核修改页表（如 munmap、mprotect、unmap、页迁移）后，其他核可能仍缓存着旧的映射，必须通过 IPI（Inter-Processor Interrupt）通知这些核失效对应 TLB 条目，否则会出现"内存已释放但 TLB 仍指向旧页"的悬挂问题。在频繁的页表操作（如大量 munmap、swap、进程切换）下，每次都要向所有可能缓存该映射的核发 IPI，就会形成 IPI 风暴，造成跨核中断开销、cache line 争用与调度延迟。工程上通过 batch 化（把多个 TLB 失效合并成一次 flush）、flush 的 lazy/deferred 优化、以及按地址空间/范围（shootdown 到确实映射该区域的核）来减少 IPI 数量。其价值在于：TLB shootdown 是保证多核虚拟内存一致性的基石，而控制 IPI 风暴是保证多核可扩展性的关键。

TLB 一致性本质上是一个"多核缓存一致性"问题，shootdown 是维持一致性的协议，IPI 风暴是该协议的开销，工程的核心是"少发 IPI、合并失效、按需失效"。

• TLBI by VA 的指令语义
• x86 INVLPGB 的广播失效
• INVPCID 的 per-PCID 失效

ARM64 的 TLBI 指令（如 TLBI VAE1IS、TLBI VAAE1）按虚拟地址（by VA）失效单个 TLB 条目，且 ARM64 有硬件广播机制——当页表修改后，各核通过 TLBI 的 broadcast 语义（by VAIS/IS 等）让系统中所有核同步失效对应条目，无需软件逐个发 IPI。x86 则有两条相关指令：INVLPGB 是较新的"广播失效"指令，能一次失效多个地址并在系统内广播，减少逐核 IPI；INVPCID 则针对 PCID（进程上下文标识符）按指定进程上下文失效，且非广播（需自己确保其他核同步）。差异在于：ARM64 依靠硬件广播的 TLBI 让跨核失效"隐式"完成，x86 传统上靠软件 IPI，INVLPGB 是 x86 试图引入硬件广播来减少 IPI 开销，INVPCID 则强调按 PCID 精细失效。实现层面 ARM64 由架构保证广播一致性，x86 更依赖软件协议与指令配合。

核心差异是"硬件广播 vs 软件 IPI"：ARM64 的 TLBI 广播把跨核失效固化到硬件，天然免去软件 IPI；x86 传统靠软件，INVLPGB 是向硬件广播靠拢的演进。

• mm_tlb_flush_sync 的同步失效
• mm_tlb_flush_nested 的嵌套失效
• 两者触发场景

在 mm/tlb.c 中，mm_tlb_flush_sync 用于在"需要立刻让其他核看到页表修改"时强制同步触发 TLB 失效（发出 shootdown 并等待相关核完成），常用于必须在返回前保证跨核一致的场景（如某些 unmap 结束后）。mm_tlb_flush_nested 则用于"嵌套的 TLB 失效"——当同一个 mm 在并发路径中（如分裂/合并页面、或进程在切换时）可能已由其他线程做过 flush，为避免重复发出 shootdown，用引用的嵌套计数（nested_flush_count）记录目前是否已处于 flush 上下文，若已嵌套则跳过冗余的 shootdown，只在最外层真正执行。两者配合：flush_sync 保证正确性（必须同步到其他核），flush_nested 通过嵌套计数做去重，减少重复 IPI。

这是 Linux 对 TLB shootdown 的优化接口：flush_sync 负责"同步一致性"的保证，flush_nested 负责"避免重复失效"的优化，二者结合在保证正确的同时削减 IPI。

• ASID 的 per-process 标识
• ASID 不足时的复用
• broadcast flush 在切换时的代价

ASID（Address Space Identifier）是硬件的进程上下文标识，让不同进程的 TLB 条目可以在 TLB 中共存而不冲突，从而避免每次切换都全量 flush TLB。但 ASID 数量有限（如 ARM64 的 ASID 位宽有限），当进程数超过可用 ASID 时，必须复用 ASID；复用前需把旧 ASID 对应的 TLB 条目全部失效（broadcast flush），否则新进程会命中旧进程的残留 TLB 条目。在频繁进程切换 + 大量进程的场景下，ASID 不断被耗尽并复用，每次复用都要做一次代价较高的 broadcast TLB flush，产生跨核失效开销。工程上通过 ASID 分配策略（如按 generation 计数、尽量让不并发进程共用 ASID、延迟复用）来减少 flush 频率，降低切换与复用带来的性能损失。

ASID 是"减少切换 flush"的优化，但 ASID 复用本身会引入"广播 flush"的代价，两者此消彼长，工程上要在这对矛盾间取得平衡。

• memory 压力下大量 unmap/回收
• shootdown 触发大量 IPI
• 延迟与逆火效应

在 cgroup v2 memory 压力下，内核会频繁进行回收（reclaim），回收过程会 unmap 大量页面，而每次 unmap 都可能导致 TLB shootdown（需让其他核失效对应 TLB）。当多核进程同时在一个内存受限的 cgroup 中运行、回收风暴发生时，大量 unmap 会触发大量 shootdown，每个核都要处理 IPI 并失效 TLB，形成"回收触发 unmap → 触发 shootdown → 核间中断 → 进一步延迟"的放大效应。此外，被 IPI 打断的核会退出空闲或繁忙状态，增加调度与上下文切换开销，使整体延迟飙升。工程上通过批量 unmap、合并 flush 范围、以及延迟/deferred shootdown 来降低压力期间的 IPI 频率，缓解延迟放大。

延迟放大源于"内存压力→回收→unmap→shootdown→IPI"的因果链，每个环节都叠加延迟，最终在压力场景下放大为明显的性能退化。

• lazy TLB 的惰性失效
• deferred shootdown 的延迟
• mm refcount 与 active_cpu 判断

当进程被切换出 CPU 时，其 TLB 条目可能仍驻留在该核的 TLB 中；若该进程在切出期间没有其他核需要修改它的 mm，那么它切回时 TLB 仍有效，无需重新失效。基于此，Linux 的 lazy TLB 允许"惰性"处理：切出进程的 mm 在 CPU 上保持"lazy"状态，若此后没有其他核对该 mm 做需要 flush 的修改，则切回时直接复用旧 TLB，跳过 IPI。关键判断依赖 mm 的 refcount：mm 记录了当前活跃的 CPU（active_cpu / mm->cpu_vm_mask），且 mm 的 refcount 会因"lazy 状态下被 pending 的 flush"而受影响。当一个核想对该 mm 做 shootdown 时，它检查该 mm 当前是否还有其他活跃/lazy CPU；若该 mm 不再被任何 CPU 引用（refcount 下降、无活跃核），则无需发 IPI。deferred shootdown 则是把 flush 延后到真正需要时（如切换回该进程时）再执行，从而合并多次失效。mm refcount 帮助判断"还有没有其他核在用它"，从而决定是否能跳过 IPI 或延迟 flush。

lazy TLB 的思想是"切走的进程没必要立刻失效其 TLB，等它回来再说"，mm refcount 提供"还有谁在用它"的依据，从而在"必须失效"与"可以跳过"之间做出正确判断。

• struct shrinker 的注册接口
• 内存压力下回调回收
• 统一 reclaim 框架

struct shrinker 允许内核子系统（如 slab kmem_cache、dentry/inode cache、filesystem cache 等）注册一个回调，当系统内存压力（内存不足、kswapd 或 direct reclaim）时，内核会调用所有已注册 shrinker 的收缩回调，让它们释放各自维护的缓存。其工程价值在于：1) 把"内存压力下回收"统一成一套可编程框架，各缓存子系统只需实现 shrink 回调即可获得回收能力，而不必自建内联回收；2) 提供可扩展的计数（count_objects）与批量收缩（scan_objects），让内核按比例回收并控制每次回收量；3) 让内核在内存紧张时能按优先级回收"可丢弃缓存"而非总是触发 OOM 或急剧 swap。这样多个缓存子系统共享同一套回收调度，既保证内存可用，又避免内存碎片与过度回收。

shrinker 是内核"可回收缓存"的标准接口，把"减少 cache"从各子系统各自为政变为统一注册、统一调度的框架，提升内存压力的应对能力。

• slab 对象回收
• page cache 页回收
• 回收对象与代价差异

slab shrinker（kmem_cache_reclaim）回收的是 slab 分配器维护的对象缓存（如 kmem_cache 中的对象、dentry/inode 等内核对象），它通过扫描 slab 的 free/slub 结构，把空闲对象归还并释放 slab 页，回收粒度是"对象"，代价是扫描 slab 元数据；page cache shrinker（drop_pagecache）回收的是 page cache 中的文件页，通过遍历 inode 的 address_space 并把干净页/可回收页释放或写回，回收粒度是"页"，代价涉及 address_space 遍历与可能的写回脏页。差异在于：回收对象不同（内核对象 vs 文件页）、实现粒度不同（对象级 vs 页级）、触发时影响不同（slab 回收影响内核内存占用，page cache 回收影响文件缓存命中率）。两者都通过 shrinker 框架统一调度，但各自处理自己的缓存类型。

两者差异本质是"回收的内容"不同：slab 管内核对象缓存，page cache 管文件页缓存，各自实现自己的扫描与释放逻辑，但共享统一的 reclaim 调度框架。

• anon 与 file 的回收权衡
• swappiness 参数影响
• inactive list 的扫描比例

vmscan 在回收内存时需要在匿名页（anon，对应 swap）与文件页（file，对应 page cache）之间分配扫描比例，这个平衡由 swappiness 等参数控制。swappiness 默认约 60，表示倾向于回收 file 页（page cache 可丢弃、代价低）而较少回收 anon 页（需要 swap 到磁盘，代价高）；swappiness 值越高，vmscan 越激进地扫描 anon 并 swap；值越低则越优先回收 file 页。vmscan 通过计算 anon 与 file 各自的比例，并按 swappiness 加权确定每轮扫描中 inactive anon 与 inactive file 的扫描量，从而在"避免 swap 代价"与"保留 file cache 命中率"之间权衡。策略的目标是按照"回收代价最小、对性能影响最小"的顺序释放内存。

scan balance 的核心是"回收代价"的权衡：file 页代价低（可简单丢弃），anon 页代价高（需 swap），swappiness 决定该保守换出多少共享内存，从而影响整体回收行为。

• memory.events 的事件字段
• 各阈值事件的触发
• SLA 监控与告警

cgroup v2 的 memory.events 提供了一个事件计数器文件，记录该 cgroup 内存压力相关的事件次数：low（触碰 memory.low 保护下限）、high（触碰 memory.high 软上限并触发 throttling）、max（触碰 memory.max 硬上限）、oom（触发 OOM 杀进程）等。工程价值在于：1) 通过读取这些计数，可以量化一个容器/工作负载在时间窗口内是否经常逼近内存阈值，从而诊断内存压力是否频繁；2) 用于 SLA 监控——当 high/max/oom 事件持续增长时，说明该容器内存不足或有泄漏，可触发告警或扩容；3) 区分"低级别压力（low）"与"严重事件（max/oom）"，实现对内存健康的精细化监控与容量规划。相比手动看 RSS，事件计数能以可量化、可聚合的方式反映内存压力，是容器内存 SLA 监控的基础。

memory.events 把"内存压力"从模糊的"占用率"变为可计数的离散事件，使 SLA 监控能基于事件频率而非瞬时占用做判断，更准确地反映服务质量。

• memory.lowmax 的语义
• 与 memory.low 的关系
• 保护上限的边界

memory.lowmax 是 cgroup v2 中 memory.low 的配套上限，用于限制"该 cgroup 得到的保护等级上限"。memory.low 表示一个软保护下限（受保护内存量），但低保护并非无上限——如果父级或兄弟 cgroup 内存紧张，某 cgroup 可能被授权超过其 memory.low 的保护，从而挤占其他 cgroup。memory.lowmax 则定义了该 cgroup 能获得的保护量上限，超过这个上限后，即使系统内存充足，该 cgroup 也不会再获得更多保护，多余部分按普通可回收处理。工程边界在于：memory.lowmax 为"保护"设定了上限，防止某个 cgroup 因 memory.low 继承或共享而无限占有保护内存，从而保证兄弟 cgroup 的内存公平性，同时避免过度保护导致资源浪费。

memory.low 是"保护的下限"，memory.lowmax 是"保护的上限"，两者共同界定一个 cgroup 实际可获得的保护范围，避免低保护被无限放大。

• memory.low 的软保护
• memory.high 的软上限
• 两者的触发条件与后果

memory.low 是"soft guarantee"（软保证）：当 cgroup 内存用量低于 memory.low 时，内核尽量保护它不被回收，即使系统内存紧张也不会轻易回收它（但并非绝对，若内存极缺仍可能被回收）；它是"保护下限"，保证该 cgroup 至少可用的内存量。memory.high 是"soft limit"（软上限）：当 cgroup 内存用量超过 memory.high 时，内核会主动触发回收并 throttling（限流该 cgroup 的分配），抑制其用量增长，但并不会立即 OOM 杀进程；超过 high 只是"被限制/被回收"，不算硬性错误。边界在于：low 定义了"保护到多少"，high 定义了"超过多少开始限制"，两者都是软性的（low 不保证绝对不被回收，high 不强制 OOM），真正强制的边界是 memory.max（硬上限，超过即 OOM）。

三者构成分级：low 是保护下限（软），high 是软上限（超了会回收 + throttle），max 是硬上限（超了 OOM）。low 与 high 的边界在于"保护"与"限制"的软性。

• memory.low 的软保护
• memory.min 的硬保证
• 是否可被回收的差异

memory.low 提供的是"软保护"：当 cgroup 内存用量低于 memory.low 时，内存在系统内存紧张时尽量不回收它，但如果系统内存极度不足、或父 cgroup 整体告急，它仍可能被回收（保护是尽力而为、可被突破的）。memory.min 提供的是"强制保证"：当 cgroup 内存用量低于 memory.min 时，内核保证不回收这部分内存（除非无其他办法），它被视为该 cgroup 的"硬性最低需求"，即使其他 cgroup 被回收也不能触碰它。差异核心在于"强制性"：memory.low 是"尽量保护、可回退"，memory.min 是"强制保留、不可触碰"。工程上 memory.min 用于保证关键工作负载的底线内存，而 memory.low 用于优先级的软性倾斜。

两者都是"保护"但强度不同：low 是软保护（可突破），min 是硬保证（不可回收），选型时按是否需要"绝对保留"来决定。

• memory.high 的软限制与 throttle
• memory.max 的硬限制与 OOM
• 从"慢下来"到"杀掉"的梯度

memory.high 是软上限：当 cgroup 内存超过 high 时，内核触发 reclaim 并 throttle（限流）该 cgroup 的分配，让进程变慢但不杀死，从而"平滑"地抑制内存增长，给负载一个减速缓冲。memory.max 是硬上限：超过 max 时内核直接触发 OOM kill（按 OOM 优先级杀掉 cgroup 内进程），是"最后的强制手段"。工程价值在于形成两级梯度：先用 high 的 reclaim + throttle 让工作负载"慢下来"适应内存约束，避免频繁 OOM；只有内存失控、无法通过 reclaim 满足时才用 max 触发 OOM。这样既保护了系统的稳定性（不无限超用），又尽量保留进程（通过减速而非击杀），是容器内存 QoS 的分级策略。

high 是"软刹车"，max 是"硬截停"，把内存压力从"可承受的减速"过渡到"不可承受的终止"，给运维以告警与调速的缓冲区间。

• flush_tlb_range 的部分失效
• flush_tlb_mm 的全量失效
• 部分失效的复杂度与全量失效的取舍

flush_tlb_mm 失效整个 mm 的所有 TLB 条目，flush_tlb_range 只失效一个地址范围。直观上范围失效更精细、代价更低，但实际可能更复杂：因为部分失效需要精确遍历并定位该范围内的每个 TLB 条目，涉及页表遍历、按范围生成失效地址、并处理可能的折叠（同一大页映射多个地址）、以及跨核广播的按范围失效逻辑；而全量失效只需简单地把整个 mm 的 TLB 清空（或把 ASID 失效），无需按地址逐条操作，实现更简单、单个失效指令即可覆盖全部。因此当失效范围很大（接近整个地址空间）、或按范围构造失效的开销接近全量时，选择 flush_tlb_mm 反而更简单高效。工程上在"范围很大"或"批量 unmap 大量页面"时倾向全量失效，在"小范围精确失效"时用 range 失效以保留其他 TLB 条目。

代价不止看"失效数量"，还看"构造失效的复杂度"：全量失效实现简单、一次覆盖，范围失效需要精确定位与遍历，范围大时全量反而更划算。

• ARM64 TLBI 的硬件广播
• x86 软件 IPI shootdown
• 可扩展性差异

ARM64 架构定义了 TLBI 指令的广播语义：当某核执行 TLBI 失效指令时，硬件通过系统内的广播机制（如 coherent 与 TLBI 广播）自动同步失效所有相关核的 TLB 条目，因此内核无需软件逐个发 IPI 去通知其他核，跨核失效由硬件"隐式"完成，减少了软件中断与核间通信开销。x86 传统上 TLB 失效不具备硬件广播，需要内核用软件 IPI 向目标核逐个发送 shootdown 请求并等待确认，复杂度与开销随核数增加。在可扩展性上，ARM64 的硬件广播在核数较少时更省事，但广播本身会打断所有核，核数增多时广播开销也可能上升；x86 软件 shootdown 可精确选择"需要失效的核"，但 IPI 协议在核数增多时开销与延迟放大。两者在"精确性"与"隐式代价"上各有取舍。

差异核心是"硬件广播 vs 软件 IPI"：ARM64 用硬件广播免去软件协议，x86 用软件 shootdown 换取精确性，可扩展性取决于广播开销与 IPI 开销的权衡。

• 层级化的 reclaim 遍历
• 由叶子向内部传播
• 保护与限制的继承

cgroup v2 的内存 reclaim 是层级化的：当某个 cgroup 超过限制需要回收时，内核会从该 cgroup 开始，按层级向它的子 cgroup 逐级传播回收请求，直到满足回收目标或整棵子树都回收完毕。回收时会考虑各子 cgroup 的 memory.low/min 保护，优先回收保护低的子 cgroup，避免破坏受保护子树的底线；同时 memory.high/max 等限制也按层级继承与传播。这种逐级传播保证：1) 内存压力在层级内被均匀分担，而非单点集中；2) 保护（low/min）与限制（high/max）在整个子树中一致生效；3) 回收从最外层/最可回收部分开始，尽量保持关键子树的可用性。本质上 reclaim 沿 cgroup 树递归，把内存压力按保护与优先级扩散到各层级。

层级化 reclaim 的核心是"沿树递归 + 按保护分配压力"，使内存上限与保护在父子 cgroup 间一致生效，形成可组合、可继承的内存管理。

• direct reclaim 的触发路径
• shrink_inactive_list 的作用
• kswapd 的后台回收

当进程在分配内存时发现内存不足，会走 direct reclaim（直接回收）路径：分配线程自己调用 shrink_zones / shrink_inactive_list 等函数，同步扫描 inactive list 并回收页面，直到回收出足够内存满足本次分配。由于 direct reclaim 发生在分配线程的上下文里，会阻塞分配线程，造成延迟。kswapd 则是内核的后台内核线程，它周期性监控各 zone 的 watermarks，当 free 内存低于 threshold 时主动唤醒，在后台执行 shrink_inactive_list 回收页面，把 free 内存维持在 comfortable 水平。协同关系是：kswapd 做"预测性、后台"回收，尽量在内存告急前提前回收，让大部分分配走正常路径；direct reclaim 做"兜底、同步"回收，只在 kswapd 来不及（内存突降）时由分配线程亲自回收。两者共享 shrink_inactive_list 等扫描逻辑，通过 watermark 与 reclaim 请求互相协调，共同维持内存水位。

kswapd 是"提前 + 后台"，direct reclaim 是"兜底 + 同步"，二者共用 shrink_inactive_list 扫描逻辑，是"后台防患"与"同步兜底"的协同。