如何使用bpf_get_current_task分析nanosleep实现纳秒级睡眠追踪？

在做延迟敏感型服务的性能分析时，粗粒度的采样往往不够用。一个线程在关键路径上频繁进入纳秒到微秒级别的睡眠，吞吐量就会莫名下降，而传统的strace因为ptrace机制的开销，会让被观测进程的延迟直接失真，观测结果基本没有参考价值。eBPF的出现改变了这个局面：它可以在内核态以极低开销挂钩定时器相关函数，配合bpf_get_current_task辅助函数拿到完整的进程上下文，从而精确记录每一次nanosleep的发生时间、持续时长和调用方堆栈。

一、bpf_get_current_task能拿到什么

bpf_get_current_task是eBPF提供的一个辅助函数，调用后会返回一个指向当前进程task_struct结构的指针。在较新的内核（5.15及以上）中还有一个变体bpf_get_current_task_btf，它直接返回BTF类型化的指针，可以在C代码里以task->pid这种字段访问的形式读取信息，写起来更自然。拿到task_struct之后，我们可以读取pid、tgid、进程名comm、优先级、cgroup信息等一系列上下文，这对于区分是哪个线程发起的睡眠非常关键。

需要注意CO-RE（Compile Once, Run Everywhere）的问题。task_struct的字段在不同内核版本之间位置变化频繁，直接硬编码偏移量会让程序在别的机器上直接崩溃。正确的做法是使用libbpf提供的BPF CO-RE机制，通过BPF_CORE_READ宏来读取字段，libbpf会在加载时根据目标内核的BTF信息自动重定位偏移量：

#include <vmlinux.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_core_read.h>

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

struct sleep_event {
    u32 pid;
    u32 tgid;
    char comm[16];
    u64 start_ns;
    u64 requested_ns;
};

struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 8192);
    __type(key, u64);
    __type(value, struct sleep_event);
} start_map SEC(".maps");

SEC("kprobe/hrtimer_nanosleep")
int BPF_KPROBE(trace_nanosleep_enter, s64 *rqtp)
{
    struct timespec64 ts;
    // 通过bpf_get_current_task_btf拿到类型化指针
    struct task_struct *task = (void *)bpf_get_current_task();
    u64 id = bpf_get_current_pid_tgid();
    u64 key = id;

    bpf_probe_read_kernel(&ts, sizeof(ts), rqtp);
    struct sleep_event ev = {};
    ev.pid = id;
    ev.tgid = id >> 32;
    // CO-RE方式安全读取comm字段
    bpf_get_current_comm(&ev.comm, sizeof(ev.comm));
    ev.start_ns = bpf_ktime_get_ns();
    ev.requested_ns = ts.tv_sec * 1000000000ULL + ts.tv_nsec;
    bpf_map_update_elem(&start_map, &key, &ev, BPF_ANY);
    return 0;
}

这段代码把每次进入nanosleep的起始时间戳记录到哈希map中，键使用bpf_get_current_pid_tgid的返回值，保证同进程多线程场景下互不干扰。函数开头的两个参数获取方式值得留意：BPF_KPROBE宏会自动帮我们处理pt_regs的上下文参数提取，比手写PT_REGS_PARM1可读性好得多。

二、追踪睡眠完成并计算真实时长

只记录进入时刻还不够，真正的分析价值在于睡眠的实际持续时间。hrtimer高精度定时器在到期后会执行回调，我们可以挂载kprobe/hrtimer_wakeup或者在较新内核上使用tp_syscall类tracepoint配合返回值探针来完成配对。这里采用更通用的做法：在nanosleep系统调用返回处挂钩，把结束时间与开始时间做差：

SEC("kretprobe/hrtimer_nanosleep")
int BPF_KRETPROBE(trace_nanosleep_exit, long ret)
{
    u64 key = bpf_get_current_pid_tgid();
    struct sleep_event *ev;
    u64 delta_ns;
    u32 hist_key;

    ev = bpf_map_lookup_elem(&start_map, &key);
    if (!ev)
        return 0;

    delta_ns = bpf_ktime_get_ns() - ev->start_ns;
    bpf_map_delete_elem(&start_map, &key);

    // 按对数分桶统计，便于观察分布形态
    hist_key = bpf_log2l(delta_ns / 1000); // 微秒级
    u64 one = 1;
    bpf_map_update_elem(&hist_map, &hist_key, &one, BPF_ANY);
    return 0;
}

使用对数直方图而不是简单平均是有讲究的。睡眠时长通常呈现长尾分布，平均值会被少数超长睡眠拉偏，而分桶统计能清楚看到主体落在哪个区间、尾部有多厚，这正是判断是否存在异常抖动的关键依据。如果把requested_ns与实际时长一起输出，还可以对比出内核调度延迟——实际时长减去请求时长，就是定时器精度与调度唤醒开销的总和，这个指标在低延迟场景下非常有价值。

还有一个容易踩的坑：如果被追踪的线程在睡眠期间被信号打断，kretprobe依然会触发，此时返回值为-ERESTART_RESTARTBLOCK或类似错误码，实际时长会远小于请求值。在直方图统计前应该先检查ret的值，把被中断的样本单独归类，否则统计结果会被污染。

三、用户态加载与结果可视化

编写完BPF程序后，需要一个用户态程序负责加载、附加探针并读取map。基于libbpf的骨架代码流程是固定的：打开elf、加载到内核、附加到kprobe点、然后周期性轮询map。对于快速验证，直接使用BCC或libbpf-tools的风格会更省事。下面是一个读取直方图的用户态片段：

#include <bpf/libbpf.h>
#include <stdio.h>
#include <unistd.h>

int main(void)
{
    struct sleep_bpf *skel = sleep_bpf__open_and_load();
    if (!skel) {
        fprintf(stderr, "加载BPF程序失败，请检查内核版本与权限\n");
        return 1;
    }
    sleep_bpf__attach(skel);

    while (1) {
        sleep(5);
        // 遍历hist_map，按桶打印分布
        for (int i = 0; i < 32; i++) {
            u64 count = 0;
            u32 key = i;
            bpf_map_lookup_elem(bpf_map__fd(skel->maps.hist_map),
                                &key, &count);
            if (count)
                printf("范围 %lu-%lu 微秒: %llu 次\n",
                       1UL << i, 1UL << (i + 1), count);
        }
    }
    return 0;
}

运行程序需要root权限或者设置CAP_BPF与CAP_PERFMON能力。如果目标机器开启了锁定模式，还要确认kernel.unprivileged_bpf_disabled的值。输出结果建议按调用方聚合：在BPF侧用bpf_get_stackid采集内核栈或用户栈，把睡眠行为与具体代码位置关联起来，这样才能从统计走向归因——知道了睡眠集中在哪一行代码，优化才有明确方向。

四、内核版本兼容与性能开销

hrtimer_nanosleep在不同内核版本中签名有过变化，早期版本第一个参数直接是 timespec64 结构而非指针，参数提取逻辑要相应调整。稳妥的做法是先查看目标内核的源码或用bpftrace -l 'kprobe:*nanosleep*'列出可用探针点再决定挂载位置。此外，如果只是想追踪clock_nanosleep系统调用，挂载tracepoint/syscalls/sys_enter_clock_nanosleep比kprobe更稳定，因为tracepoint的参数格式由内核保证兼容，不会随版本悄悄变化。

关于开销，实测单个探针的执行耗时在百纳秒量级，对吞吐的影响通常可以忽略，但这不代表可以无节制地挂钩。如果目标服务每秒发起数百万次短睡眠，map操作的累计成本就不可小觑，此时建议在BPF侧做预聚合（直方图统计就是典型手段），避免把原始事件一股脑送到用户态。另外哈希map在极端并发下可能出现更新冲突，把BPF_F_NO_PREALLOC标志去掉换用预分配模式，可以减少内存分配抖动，让观测工具本身不至于成为延迟来源。

总结来说，bpf_get_current_task提供了进程上下文的入口，配合kprobe与map统计，就构成了纳秒级睡眠分析的完整链路：记录起点、配对终点、分桶统计、关联调用方。掌握这套方法后，类似的时间行为分析比如futex等待、定时器精度测量都可以举一反三地实现。

eBPFbpf_get_current_tasknanosleep修改时间：2026-09-15 16:46:41