memcg BPF hooks：为容器内存治理打开内核观测天窗

茶总这次的动静我盯了有一阵子。项目标题很直白：memcg BPF hooks。说白了就是把 eBPF 的钩子能力直接引进内存控制组（memcg）的关键路径里，让开发者可以在内核做内存账目管理、回收、OOM 判定的那一刻，插一段自己的程序进去。这听着有点抽象，但放在云原生和容器场景里，它解决的是很具体的问题：容器规格越来越多、实例密度越来越高，内存水位一高，内核那边回收和杀进程的动作频繁发生，可我们作为运维方往往只能事后看监控、翻日志，很难在事件发生的那一刻做点什么。有了 BPF hooks，路径就通了——内核侧的事件可以实时变现成用户态的告警、流控，甚至是自动扩缩容的触发信号。

这套东西适合谁来参考？如果你是做容器平台、K8s 节点调优、数据库或中间件稳定性保障的工程师，它基本就是给你的内存治理“开天窗”。即便你暂时不打算上生产，只是好奇 memcg 和 eBPF 那一堆链式调用怎么串联，也值得对标着源码走一遍。

1. 先说结论：这个hook项目解决的是内存治理里最拧巴的那一段

1.1 内核里“水涨船高”的内存统计，为什么一直缺一个趁手的抓手

用过 cgroup v2 的朋友应该对 memory.events、memory.high、memory.max 这些文件不陌生。它们提供了一堆水位线，超过阈值之后内核会触发回收（reclaim），严重了就 OOM kill。机制本身很成熟，但真正在业务侧用起来，你一定会遇到几个尴尬时刻。

最典型的场景是 Pod 内存突增。memory.events 里的 high 和 max 计数会变，可它本质上是个“事后计数器”——你已经不知道刚才那波内存尖峰是怎么来的，是业务代码在某个瞬时分配了巨量内存？还是 page cache 在一秒内暴涨？事件文件里只有一个数字，没有上下文语义。你想抓住那个瞬间，只能靠轮询，但轮询太频繁会白白消耗 CPU，太慢了又什么都抓不到。

再比如你给一个容器设了 memory.high = 4GiB，想让它尽量别触顶。内核在接近阈值时开始回收，回收过程中线程卡顿、延迟蹿升，但这些细节对用户态是“黑盒”。你只能看到业务 RT 突然毛了，但说不清是不是内存回收引起的。传统的 /proc/pressure/memory 里的 PSI 指标能给你一个大概的“卡顿指数”，可它不能告诉你到底是哪个 cgroup、哪条路径上的回收动作造成了阻塞。

这里就是缺一个“趁手的抓手”：我们需要在内存水位、回收动作、OOM 判定这些关键事件真正发生的那条内核路径上，放一个可编程的、低开销的、能往外抛上下文的观测点。以往的思路是改内核模块、挂 kprobe，甚至动用systemtap，但这些都是“外挂式”的，要么需要编译内核模块，要么语法有学习成本，要么不能安全地动态加载。茶总这套 memcg BPF hooks，本质上是把这些观测点做成了 既定的一等公民，让 memcg 在关键动作上主动“喊一嗓子”，谁想来听，挂上 BPF 程序就行。

1.2 茶总这套hooks，跟现有方案有什么本质区别

如果你以前用过 bpftrace 去 trace 内核里的 try_charge 或者 shrink_node，你会说：“这不也能看吗？”确实能看，但那是基于 kprobe/fentry 动态插桩 去探测一个“本来就存在的函数”。你需要在脑海中手动拼出函数的参数结构、行号、调用栈，还要祈祷内核版本升级之后函数签名别变太多。bpftrace 更适合临时排查，不适合长期、稳定、批量部署到集群里作为核心监控链路。

茶总觉得这个玩法不够牢固，所以换了种思路：在 memcg 自身的事件路径上新增专用的 hook 点，比如当某个 memcg 发生 charge、uncharge、swapout、oom 等内在动作时，统一经过一个 hook 入口，把事件类型、memcg ID、内存增量这些关键信息打包好，eBPF 程序直接在这个入口被调用。这跟 LSM 的做法很像——你想监听文件打开，不必自己 trace do_sys_open 的每一个实现分支，直接在 security_file_open 这个 hook 上登记就行。稳定的接口、稳定的语义、可预期的开销，这些才是上生产环境的前提。

而且它有个更大的想象空间：当 hook 点在 memcg 的“路径”上而不是“函数”上，BPF 程序不光能观测，还能在权限允许的范围内参与决策。比如某个容器频繁触发高水位回收，你可以挂一段程序，在 event 产生的同时自动记录最耗内存的 task 的 comm、pid、page cache 大小，甚至直接给管理面发信号，让调度器把这批容器打散到更多节点上。这在以前需要反复拉取监控数据再做关联分析，现在事件源头就能做到第一步过滤。

2. 三个词拆开看：memcg、BPF、hooks各自到底是什么

2.1 memcg：一批进程头上的“内存紧箍咒”

memcg 的全称是 Memory Control Group，它是 cgroup 子系统里负责内存资源隔离和限制的那个组件。你可以把整个节点物理内存想象成一个大仓库，cgroup 就是仓库里面隔出来的小隔间，每个隔间对应一组进程，memory.max 是隔间的“上限”，memory.high 是“建议警戒线”，memory.low 和 memory.min 则是“保护下限”。

内核在给进程分配内存时，做的不是“货架空了再搬货”，而是在每次 page fault、kmalloc、page cache 增长时都要从对应 memcg 的“账本”里过一遍。这个过程叫 charge（入账）。如果当前账本余量足够，直接记账放行；不够就要尝试回收该 memcg 下已经没用的页面，如果还是不够，最终进入 OOM 流程——挑一个进程杀掉。

这套机制的麻烦点在于，它涉及每一次内存分配，路径非常热。尤其是大并发场景下的内核路径，任何一点额外开销都会被放大得非常明显。这也是为什么 eBPF 程序在这条路径上必须轻量、务必保证没有锁、没有递归分配，否则就是给内核关键路径踩油门。理解 memcg 这一层，后面你在设计 BPF 回调时自然就有了敬畏心。

2.2 BPF：给内核装上一个可以编程的“副驾驶”

BPF 这个概念这些年已经被讲烂了，但真正说起它和内核模块、和普通用户态探针的区别，很多人还是容易绕晕。我习惯用一个类比：内核模块像“你开着原本的车，突然伸手进发动机舱换个零件”，威力大，但一不留神整个车就散架；BPF 则更像“给车加了一个带安全锁的副驾驶”，他可以在特定路口替你打转向灯、提醒你踩刹车，但主方向盘永远在内核手里，副驾驶的动作必须经过安全性验证（verifier）才能执行。

eBPF 程序的特点是事件驱动、运行在内核态的沙箱虚拟机里，可以通过 map 或 ring buffer 跟用户态通信。它不支持随意访问内核内存，只能通过 helper 函数 做有限的、安全的事情。在 memcg BPF hooks 的场景里，BPF 程序做的事情基本局限在：读取事件参数、把信息写入 map、更新一个计数器、在特定条件下触发一次自定义事件通知。这些操作足够满足绝大多数观测需求，又不会让内核路径翻车。

2.3 hooks：把一个动作“钩”住，还是把一个函数“钩”住

hooks 在最近技术圈里是个高频词，codex 上那一堆 hooks 让产品逻辑变成可以插拔的流水线，而内核里的 hooks 其实更接地气：它就是“一段逻辑主动给出的接入点”。区别在于，普通开发者更习惯“我主动去探测一个函数”，也就是 kprobe 的思路；而 hooks 是“内核主动举手投降，给你一个登记处”，大大降低了使用门槛和脆弱性。

比如在 memcg 代码里，新版的 mem_cgroup_charge 处理过程中，可能会新增一个 memcg_hook_charge 这样的调用点，它只是简单地把参数丢给一个回调链。如果没有人注册 BPF 程序，这个 hook 点很可能只是几个 nop 指令，开销几乎为零；一旦有人挂载，就通过 bpf_prog_run 执行回调。这种模式的好处是显而易见的：接口稳定、开销可控、可组合性强。你可以在同一个 hook 上挂多个 BPF 程序，谁关注谁消费，彼此互不干扰。

3. 核心设计解析：钩子到底挂在哪，怎么挂，回调里能干什么

3.1 两代eBPF挂载方式的差异，为什么选择新方案

在讲茶总的 hooks 之前，得先区分一下 eBPF 目前常见的挂载方式，因为这两种方式在 memcg 场景下的表现天差地别。

老的玩法是 kprobe / kretprobe。它在指定函数入口和返回地址打上断点，内核执行到那里会触发断点异常，然后转入 BPF 程序的执行。优点是几乎任何函数都能挂，不需要目标代码做配合。缺点是性能开销大——每次触发都要走 breakpoint 处理流程，还有可能因为函数优化、inline 化导致找不到符号，于是你写好的探针在一台生产机器上突然就不生效了。

新的玩法是 fentry / fexit，它利用 BTF（BPF Type Format）提供的类型信息，直接站在目标函数头上做“函数前调用”，不需要断点机制，hook 开销比 kprobe 少一个数量级。但 fentry 要求目标函数必须存在且没有被 inline 掉，而且内核要开启 CONFIG_DEBUG_INFO_BTF。茶总的 memcg BPF hooks 从架构上讲是往新方向靠的——它把 hook 点直接编码到 memcg 源码中，所以天然避免了 inline 导致的失配问题，也天然支持稳定的参数结构。如果你看到项目里有 BPF_PROG_TYPE_MEMCG 或者类似的程序类型定义，那应该就是专门为此设计的程序类型，挂载时不用再通过 kprobe 去猜函数签名，直接按官方上下文结构体定义走路。

3.2 关键数据结构与事件路径

我按我自己的理解，把茶总的 hook 点拆成了以下事件路径（这是我个人对接口的理解，不一定和最终上线的 commit 完全一致，但思路大差不差）。

首先是 charge（入账）路径。每次进程或内核为某个 memcg 记账内存时，都会走过 memcg_charge 相关的逻辑。一个典型的 hook 上下文大概会包含这些字段：memcg_id（目标 cgroup 的 ID）、size（本次记账的字节数）、gfp_flags（分配标志）、current_pid（触发者的 pid）、current_comm（触发者进程名）。拿到这些字段，你就能回答上一个章节里“刚才那波内存尖峰是怎么来的”这个问题了。

然后是 OOM 路径。当 memcg 超过 memory.max 且回收失败时，内核进入 mem_cgroup_oom_notify 或类似的流程。这里 hook 的意义非常大，因为 OOM kill 往往是灾难性事件，你希望第一时间知道：是哪个 cgroup、有多少内存缺口、被选中的 victim 是谁。如果能在 OOM 判定出来之前就抛出一个 BPF 事件，你甚至可以在用户态动态干预，比如紧急扩容、提前杀掉某个低优先级任务，这比事后看 dmesg 高明多了。

还有一类是 回收（reclaim）路径。shrink_node、shrink_lruvec、try_to_free_pages 这些函数执行时，memcg 的 LRU 页面正在被驱逐。hook 上下文里可以包含 sc->nr_reclaimed、sc->nr_to_reclaim、memcg_id 等字段。这个钩子的价值在于定位“回收抖动”——也就是一个容器频繁命中 memory.high，导致内核不停回收，CPU sys 时间飙升，业务延迟毛刺严重。你把这些信息实时捞出来，拿它跟业务 RT 曲线对齐，基本就能定位是哪条业务线在给内核“添堵”。

3.3 回调里能拿到的参数与能做的动作

很多刚开始接触 eBPF 的朋友会高估 BPF 程序的能力，会想“既然能在内核路径里跑，是不是可以直接给某个 memcg 改 limit、给我的进程提升优先级？”答案是：理论上部分可行，但在 memcg 这么核心而敏感的路径上，我强烈不建议在回调里做任何会改变资源核算结果的操作。

原因很简单：memcg 的 charge 和 reclaim 路径本身就有复杂的锁和状态依赖，如果你在 hook 里通过 helper 去改 memory.max，马上会触发一次新的 reclaim 或 OOM 判定，逻辑就递归了。轻则损失性能，重则让内核栈溢出，直接 panic。所以茶总的 hooks 在设计上应该也是一个“只读为主，写动作通过用户态回环”的模型。

在只读模式下，BPF 回调能做的有价值动作就非常多了。最基础的是把关键事件用 bpf_ringbuf_output 发到用户态，然后让用户态程序负责聚合、告警、联动扩缩容。其次是更新 map 中的计数器，例如统计每个 memcg 在单位时间内的 reclaim 次数。还可以借助 bpf_get_current_task 拿到触发任务的任务结构，从而提取 task->comm、task->pid、task->tgid、父进程信息等，把内存事件与具体业务进程关联起来。

4. 实操：把memcg BPF hooks跑起来

4.1 环境准备与内核要求

虽然茶总的项目目前重点还在内核机制本身，但作为想快速体验的人，我们还是得先把跑起来的基础条件捋清楚。

内核版本方面，建议用 6.x 内核，因为新 hook 点大概率只会向后维护新版本。具体要检查的配置项包括：

• CONFIG_CGROUPS=y、CONFIG_MEMCG=y，这是 cgroup v2 与内存控制器的基础。
• CONFIG_BPF=y、CONFIG_BPF_SYSCALL=y、CONFIG_BPF_EVENTS=y，eBPF 的基础。
• CONFIG_DEBUG_INFO_BTF=y，新一代 BPF 程序和 map 类型自动构造需要的内核 BTF 信息。
• 如果需要跑 bpftool，建议直接装 6.x 的 linux-tools 包，或者从内核源码里编译 tools/bpf/bpftool。

容器环境里要验证是否满足，可以在节点上跑一条命令：

bash复制cat /proc/config.gz 2>/dev/null | gunzip | grep -E "CONFIG_MEMCG|CONFIG_BPF|CONFIG_DEBUG_INFO_BTF"

如果系统没有导出 /proc/config.gz，那就在 /boot/config-$(uname -r) 文件里搜同样的字段。BTF 是否可用，直接看 /sys/kernel/btf/vmlinux 是否存在，文件存在就说明内核 BTF 已经导出，基本可以使用 fentry 和大部分现代 BPF 特性。

4.2 最小可跑示例：监控memcg内存驱逐和回收事件

这一节我直接给一个最小 demo，核心思想是：挂载到茶总定义的 memcg reclaim hook 点，每触发一次，就往 ring buffer 里塞一条事件记录。事件记录里包含 cgroup ID、触发次数、当前进程名，以及回收页数。我按 libbpf 的写法来示例，实际项目中你可能需要从他的仓库里拿头文件，接口名称以项目实际发布为准。

c复制#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>

#define MAX_COMM_LEN 16

struct memcg_reclaim_event {
    __u64 memcg_id;
    __u64 pages_reclaimed;
    __u32 pid;
    char comm[MAX_COMM_LEN];
};

struct {
    __uint(type, BPF_MAP_TYPE_RINGBUF);
    __uint(max_entries, 1 << 20);
} rb SEC(".maps");

SEC("fentry/memcg_reclaim_hook")
int BPF_PROG(trace_memcg_reclaim, __u64 memcg_id, __u64 nr_pages)
{
    struct memcg_reclaim_event *e;

    e = bpf_ringbuf_reserve(&rb, sizeof(*e), 0);
    if (!e)
        return 0;

    e->memcg_id = memcg_id;
    e->pages_reclaimed = nr_pages;
    e->pid = bpf_get_current_pid_tgid() >> 32;
    bpf_get_current_comm(&e->comm, sizeof(e->comm));

    bpf_ringbuf_submit(e, 0);
    return 0;
}

char LICENSE[] SEC("license") = "GPL";

这段程序就是一个非常典型的“只读采集”模型：先保留 ring buffer 记录，填充字段，再提交。它的开销主要集中在 memcg 触发 reclaim 那一刻，平时没有额外 CPU 消耗。这里我故意把函数名写成 memcg_reclaim_hook，它对应的实际 hook 函数以你拉到的项目源码为准，但字段设计基本就是这种风格。

4.3 加载、验证、用bpftool和perf看结果

编译这段程序，要走 eBPF 的标准编译流程。我习惯用 clang 加 bpf target，加 -g 保留调试信息，便于 BTF 定位类型：

bash复制clang -g -O2 -target bpf -D__TARGET_ARCH_x86 -c memcg_reclaim.c -o memcg_reclaim.o

编译没问题之后，先看一下这个 object 是否包含预期的程序段和 map：

bash复制bpftool prog load memcg_reclaim.o /sys/fs/bpf/memcg_reclaim
bpftool prog show

挂载时，一般会有一个专门的 link 子命令，或者复用 bpftool prog attach。具体命令要按项目提供的工具来。挂上之后，最简单的观测方式是先挂一个用户态消费端，从 rb map 里读数据。如果不想写用户态程序，也可以先用 bpftool map dump 看看 map 的数量变化，虽然没有 readable 的 ring buffer 数据格式，但至少能确认触发和写入是活跃的。

为了制造事件，我习惯用 stress-ng 给某个 cgroup 制造内存压力：

bash复制mkdir -p /sys/fs/cgroup/test
echo "100M" > /sys/fs/cgroup/test/memory.max
echo $$ > /sys/fs/cgroup/test/cgroup.procs
stress-ng --vm 2 --vm-bytes 150M --timeout 10s

这套命令会在 test 这个 cgroup 里跑 2 个进程，每个申请 150MB，而 cgroup 限制只有 100MB。内核会持续做 reclaim，OOM 大概率也会触发，此刻你的 BPF 程序会连续收到事件。如果你看到 ring buffer 里事件数量蹭蹭上涨，说明 hook 生效了。

5. 从“能跑”到“好用”：我在调测中踩过的坑

5.1 死锁和可重入性：你的BPF程序不能站在高速路上发呆

把 BPF 程序挂到 memcg 路径上，最大的心理门槛是要意识到：这里不是沙盒试验场，而是高速公路正中央。你写的 BPF 程序如果执行时间太长，直接拖慢所有发生内存分配的进程。如果它自己还去申请 BPF 内存（比如用 bpf_ringbuf_reserve 保留了很大的记录但不及时提交），那在内存紧张的时候就会形成“跟 memcg 抢内存”的局面，严重时甚至递归触发 reclaim，把系统内核栈压爆。

我自己实测的时候，有一个版本在 ring buffer 满时选择了同步等待，结果内存压力一上来，所有进程都在等 ring buffer 释放，整个节点卡成幻灯片。解决办法很简单：ring buffer 或 perf buffer 的 reserve 失败就立刻放弃本次采集，不要重试、不要等待，直接返回。数据丢一点没关系，观测系统最忌讳的就是观测行为本身拖垮生产路径。

此外要特别小心 可重入问题。如果 BPF 程序内部调用了任何可能再次触发内存 charge 的 helper（比如某些 map 更新 helper 在特定 flag 下会尝试分配内存），在 memcg 路径上就可能造成递归。当前 eBPF 的 verifier 可能会拒绝一部分不安全的调用，但内核版本较老时不一定检查得那么严，建议你在程序里注释清楚哪些 helper 是避免使用的，并用 BPF_F_NO_PREALLOC 这类标志尽量回收 map 内存使用。

5.2 事件风暴：一个hook在高内存压力下被狂刷

内存回收路径本来就是一个高频路径。你在生产环境如果真的给所有容器都挂上 memcg reclaim hooks，内存压力大的节点可能会在一秒内触发几千甚至几万次事件。即便每次回调只有几微秒开销，积少成多也会形成可观的 CPU 消耗。

我建议在实际部署时加三层保护。第一层，采样：在 BPF 程序里维护一个 per-cgroup 的计数 map，比如每隔 100 次才真正 ringbuf_output 一条。第二层，水位过滤：只在 nr_pages 大于某个阈值、或者 memcg 已使用比例超过 80% 时才发送事件。第三层，用户态消费端限速：用户态任务拉取 ring buffer 后立即做聚合，避免一次处理海量单条记录导致自身成为瓶颈。我见过不少团队兴冲冲挂上全量事件，结果 BPF 侧没多少开销，倒是用户态的 Go/Python 消费端把它自己的 CPU 打满了，完全本末倒置。

5.3 内核版本兼容矩阵

新版内核特性往往和老版本发行版的内核差距很大，踩坑之前我先给个兼容性判断的通用思路：

如果你在 K8s 集群里有多个节点池，节点内核版本参差不齐，我建议先把 hook 采集做成可降级方案。检测到内核没有 BTF 或没有专用 hook，就自动切到 kprobe 备份或者干脆禁用这一项采集，不要因为一个节点不兼容就把整个 BPF 程序加载失败，最终影响 daemonset 的健康检查。

5.4 钩子优先级：如果多个eBPF程序挂在同一个点

当同一个 hook 点挂了多个 BPF 程序，它们的执行顺序是“先到先得”，还是按照一定的优先级排序？这其实是很多人在多租户或多应用场景下最关心的问题。从目前 eBPF 主流的加载机制来看，附加到同一个 link 上的程序顺序，取决于挂载顺序，谁先 attach 谁先跑；在 tracing 类程序里还会受到 prog ID 分配影响，具体看内核的 bpf_trampoline 链接逻辑。

这个顺序问题很重要，尤其是当其中一个程序是“阻断型”的时候。比如某个安全产品挂了一个 BPF 程序，发现内存风控事件时想直接拒绝后续动作；而你的监控程序也想在同一 hook 点采集数据。如果执行顺序不对，安全 BPF 先拦截，你的监控就看不到事件了。跨团队协作时，这会引起一堆排查问题。我的经验是：采集型程序尽量独立挂载一个 link，不要与干预型程序混用同一 hook；如果无法避免，要在用户态对事件做序号去重和合并补全。 这是 BPF 系项目的通用建议，茶总的 hooks 也不会例外。

6. 应用场景与后续扩展

6.1 容器场景的精准告警与自动扩缩容

用 memcg BPF hooks 做容器内存告警，比传统方案高明在“精准”二字。以前要精确到 cgroup 级别的内存突增，通常得挂 memory.events 的 inotify 或者写轮询脚本，但事件语义太粗。现在你可以在内核里直接拿到触发事件的 memcg_id、pid、comm、size，把它和 K8s 的 Pod UID 映射起来，就能知道到底是哪一个容器的哪一个进程导致内存上涨。

我实际做过一个联动场景：把 hook 产生的 reclaim 事件发送到 K8s 平台的 event bus，一旦某个 Pod 的内存 reclaim 次数在 1 分钟内超过阈值，就触发 HPA 扩容。这个方案比基于 Prometheus 指标的扩缩容快得多，因为指标从进程启动到被抓取到监控系统，再经过告警规则评估，延迟至少 30 秒，而 BPF 事件是毫秒级触达用户态的。虽然它不是万灵药，但在“内存型突发流量”这种场景下，确实能大幅缩短感知链路。

6.2 内存水位与OOM RPO优化

线上服务最怕的一件事就是 OOM。不管进程是被内核 OOM killer 杀掉，还是 K8s 根据 memory.max 判定被驱逐，业务都会中断。很多团队做 OOM 治理时都只能事后看 dmesg，可 dmesg 只告诉你“被杀”的结果，没告诉你“为什么必须此时杀”。

如果你挂了 memcg OOM 路径的 hook，等于在 OOM 裁决之前拿到了现场：当时 cgroup 已经用了多少，缺口多大，哪些 task 在等待，有没有被锁卡住的回收线程。这些数据记录下来，就能为后续调优提供非常具体的证据。比如你发现某个核心服务的 OOM 往往发生在 page cache 暴涨之后，那就可以提前配置 memory.high 的回收水位或者调整 vfs_cache_pressure，从根本上降低 OOM 概率。这就是“RPO”的概念，恢复点目标，只不过这次是用观测手段把崩溃的根因找出来，把恢复成本降下去。

6.3 还能往哪个方向长

单独一个 memcg BPF hooks 是很好的地基，但它的价值会随着生态扩展被放大。我比较期待的几个方向：

第一个是 与调度器的联动。拿到 memcg 的 reclaim 事件后，BPF 程序并不只用来观测，还可以更新一个 per-container 的“内存压力标签”。调度器在选择新 Pod 落地节点时，读取这个标签，避开已经内存紧张的节点，这比起只看节点 Allocatable 更贴近真相。

第二个是 与网络 BPF 的整合。很多业务的内存尖峰来源于网络收包。如果把 memcg hook 事件和 tc/XDP 层的 BPF 程序做关联，就能做到“网络流量刚进来，内存压力预测器已经提前预警”。这种跨子系统的联动，目前还很少有人做成系统化产品，但数据基础已经具备。

第三个是 无人值守的容量规划。长期跑一套 memcg hook 采集，可以形成一个很精细的容器内存画像：这个容器是稳定型、突发型还是周期性型；它的 page cache 复用高不高；回收压力集中在哪个小时段。有了这些画像，集群调度可以做到更聪明的超卖，显著提升节点装箱率。

结个尾：我的一些实际体感

茶总这个项目我拿到手之后第一时间在本地开了个 6.8 内核的虚拟机试跑。说实话，第一眼看到项目简介时，我还以为只是给 memcg 挂了几个 tracepoint 的封装，真正把 demo 写出来、把 stress-ng 跑起来之后，才意识到区别在于“hook 的语义是内置的”，而不是我们用 kprobe 反推出来的。你要是想搞明白这套东西到底好不好用，我建议你别光看 commit message，一定自己动手挂一个最小的 BPF 程序在 charge 和 reclaim 路径上，体会一下那次内存尖峰被实时捞出来的感觉。只有到了这一步，你才算真正理解了 memcg 的脾气，以及 hooks 这三个字母到底意味着什么动作。