如何在Golang中通过eBPF追踪内存缺页事件-Golang-PHP中文网

不能直接用 tracepoint:exceptions:page-fault-user，因其在5.10+内核被移除、架构受限、不区分缺页类型且不暴露虚拟地址和映射信息；需hook内核缺页函数并结合mmap特征识别Go内存区域。

如何在golang中通过ebpf追踪内存缺页事件

为什么 `page-fault` 事件在 eBPF 中不能直接用 `tracepoint:exceptions:page-fault-user`？

因为 Linux 内核的 exceptions:page-fault-user tracepoint 并非稳定接口：它在 5.10+ 内核中被移除，且即使存在，也只在特定架构（如 x86）上触发，ARM64 默认不启用。更关键的是，该 tracepoint 不区分缺页类型（major/minor），也不暴露触发缺页的虚拟地址和内存映射信息——而这恰恰是定位 Go 程序内存问题的核心。

真正可靠的方式是 hook do_page_fault（ARM64）或 do_user_addr_fault（x86_64）内核函数，但 Go 程序的缺页行为有特殊性：大量缺页发生在 mmap 分配的匿名内存（如堆、goroutine 栈）上，而 Go runtime 自己管理这些区域，不会走常规的 handle_mm_fault 路径。所以必须同时覆盖：

handle_mm_fault —— 普通用户态 mmap 缺页（如大块切片首次访问）
do_anonymous_page / do_swap_page —— 匿名页/换入页路径（Go 堆分配常见）
__do_sys_mmap + __do_sys_munmap —— 辅助判断哪些 vma 是 Go runtime 创建的（通过 prot 和 flags 推断）

如何让 eBPF 程序识别 Go runtime 分配的内存区域？

Go runtime 在调用 mmap 分配堆或栈时，会设置特定的 prot 和 flags 组合：比如 goroutine 栈通常为 PROT_READ|PROT_WRITE + MAP_ANONYMOUS|MAP_PRIVATE|MAP_STACK；而堆区（如 runtime.sysAlloc）常用 MAP_ANONYMOUS|MAP_PRIVATE，且 len 往往是 2MB 对齐（大页 hint）。eBPF 无法直接读取 userspace 的 runtime.mheap，但可通过以下方式交叉验证：

在 __do_sys_mmap 返回路径中，用 bpf_get_current_pid_tgid() 匹配 Go 进程 PID，并记录返回地址（ret）、addr、len、prot、flags 到 per-CPU hash map
在 handle_mm_fault entry 中，用 args->address 查找最近一次 mmap 的 vma 起始地址（需配合 bpf_probe_read_kernel 读取 struct vm_area_struct 的 vm_start 字段）
若命中且 vm_flags & VM_WRITE && vm_flags & VM_ANON，再检查该 vma 是否在已记录的 mmap 地址范围内 —— 若是，大概率是 Go runtime 分配

注意：vm_area_struct 在不同内核版本字段偏移不同，必须用 #include + bpf_core_read（CO-RE）读取，硬编码 offset 在 5.15+ 上会崩溃。

怎样从缺页上下文中安全提取 Go 协程 ID 和函数调用栈？

eBPF 不能直接调用 runtime.g 或解析 Go 的 G 结构体（无 DWARF 符号时不可靠），但可利用两个事实：

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

Go 协程切换时，会把当前 G* 存入寄存器（x86_64 是 gs:0x0，ARM64 是 tpidr_el0）
Go 1.17+ 使用 PC-相对调用，栈帧中 runtime.gentraceback 调用前，rbp（x86）或 fp（ARM64）指向 goroutine 栈底附近

实操建议：

在 handle_mm_fault kprobe 中，用 bpf_get_current_task() 获取 task_struct*，再通过 bpf_core_read(&g_ptr, sizeof(g_ptr), &task->thread.uw.fpsimd_state)（不推荐）或更稳妥的：用 bpf_probe_read_kernel(&g_ptr, sizeof(g_ptr), (void*)gs_base + 0) 读取 gs 段首字节（Go runtime 将 G* 放在 gs:0）
用 bpf_get_stackid(ctx, &stack_map, 0) 获取内核栈，再用 bpf_get_stackid(ctx, &go_stack_map, BPF_F_USER_STACK) 获取用户栈 —— 但 Go 用户栈可能被 runtime 移动，需配合 runtime.curg 地址校验
最轻量方式：不解析 G，只记录 current->pid + current->comm（即 "myapp"）+ 缺页地址 + 时间戳，后端用 pprof 或 perf script 关联 Go 符号

为什么用 `libbpfgo` 而不是 `ebpf-go` 加载程序？

ebpf-go（aka cilium/ebpf）对 CO-RE 支持较弱，且默认使用 perf_events 输出，难以与 Go runtime 的 GC 周期对齐；而 libbpfgo 直接封装 libbpf C API，支持：

自动加载 BTF 并重写 bpf_core_read 字段访问（避免内核结构体变更导致的 crash）
用 ringbuf 替代 perf_buffer，降低丢包率（缺页事件密集时 perf_buffer 易 overflow）
允许在 Go 侧注册 RingbufCallback，直接将事件反序列化为 struct，无需 unsafe.Pointer 手动解析

示例关键代码片段（Go 侧）：

spec, err := LoadMemfaultEbpf()
if err != nil {
    log.Fatal(err)
}
obj := &MemfaultEbpfObjects{}
if err := spec.LoadAndAssign(obj, &ebpf.CollectionOptions{
    Programs: ebpf.ProgramOptions{LogLevel: 1},
}); err != nil {
    log.Fatal(err)
}
rb, err := libbpfgo.NewRingBuffer("events", obj.IssuePagefault.RingBuf, func(data []byte) {
    var evt PageFaultEvent
    binary.Read(bytes.NewReader(data), binary.LittleEndian, &evt)
    log.Printf("pid=%d addr=0x%x major=%t", evt.Pid, evt.Addr, evt.Major)
})
if err != nil {
    log.Fatal(err)
}
rb.Start()

真正难的不是写 eBPF，而是让 Go runtime 不把 eBPF map 当成可回收内存 —— 必须在 Go 初始化时用 C.mmap 预占一段虚拟地址，再用 bpf_map__set_initial_value 绑定 map，否则 runtime GC 可能误判并释放 map 内存。