在做线上性能排查时，我们经常能看到进程处于S状态，栈信息里赫然写着ppoll或者poll_schedule_timeout，但光靠这样的栈信息，很难判断出进程到底在等哪个fd、等了多久、被谁唤醒。strace虽能看到系统调用参数，但开销巨大且无法在生产环境长期挂载。eBPF的出现改变了这个局面，配合bpf_get_current_task辅助函数，我们可以在几乎零开销的前提下，把ppoll调用的完整上下文抓出来，实现真正意义上的高精度IO多路复用分析。
ppoll与poll的区别到底在哪里
先厘清一个容易被忽视的概念。poll和ppoll在用户态接口上非常接近，核心差异有两点：第一，ppoll的超时参数是一个timespec结构，精度达到纳秒级，而poll用的是毫秒级的int；第二，ppoll额外支持sigmask参数，能在等待期间原子地替换信号掩码，避免了poll加sigprocmask组合时经典的竞态窗口。内核侧两者最终都收敛到do_sys_poll这个公共路径，超时会被统一换算成ktime_t，所以从内核视角看，两者的等待逻辑基本一致。
这意味着一个重要的实践结论：用eBPF监控ppoll时，挂载点不应该去找名为ppoll的函数，而是应该关注sys_enter_poll和sys_exit_poll这对tracepoint（或者对应平台上do_sys_poll的kprobe）。glibc的ppoll包装函数发起的系统调用号就是SYS_poll，内核tracepoint层面只有poll这一个名字。很多初学者在这里踩坑，写了一个针对ppoll的kprobe却始终抓不到数据，原因就是内核里根本没有这个符号。
另外一个值得关注的点是ppoll的timeout精度。虽然接口宣称纳秒级，但实际精度受内核定时器框架限制，通常是毫秒到微秒量级。不过对于监控而言，这个精度已经足够把IO等待和调度延迟区分开来，这正是我们做高精度分析的基础。
bpf_get_current_task能给我们什么
bpf_get_current_task是eBPF的一个辅助函数，它的作用是在BPF程序执行时返回指向当前进程task_struct的指针。拿到这个指针后，配合BPF CO-RE（Compile Once, Run Everywhere）技术，通过BPF核心读取辅助宏，可以安全地访问task_struct内部的字段，比如进程的pid、tgid、comm、线程组信息，甚至通过real_parent追溯到父进程。
在分析ppoll这类多路复用调用时，这个函数的价值非常突出。生产环境的服务大多是多线程架构，poll的调用发生在各个工作线程上，如果只靠bpf_get_current_pid_tgid，我们只能拿到线程的pid，无法方便地区分这个线程属于哪个进程的主逻辑。而通过bpf_get_current_task获取task_struct后，可以一次性读取tgid、pid、comm三个字段，把线程归属关系完整还原出来，输出的表格直接可读。
需要注意使用限制。task_struct属于内核内存，BPF程序不能直接解引用，必须使用bpf_core_read或bpf_probe_read_kernel这类的受控读取方式，否则verifier会直接拒绝加载。同时不同内核版本的task_struct字段布局有差异，建议使用vmlinux.h配合字段偏移重定位，而不是手写偏移量。
完整代码示例：统计每个线程的ppoll等待时长
下面用BCC实现一个完整的监控工具。思路是在sys_enter_poll时记录进入时间戳和线程信息，在sys_exit_poll时计算差值并汇总。为了演示bpf_get_current_task的用法，pid和进程名都从task_struct中读取。
#include <uapi/linux/ptrace.h>
#include <linux/sched.h>
// 记录调用开始时间
BPF_HASH(start, u32, u64);
// 输出统计结果
BPF_HASH(latency, u32, u64);
TRACEPOINT_PROBE(syscalls, sys_enter_poll)
{
struct task_struct *task = (struct task_struct *)bpf_get_current_task();
u32 pid = 0, tgid = 0;
// 通过CO-RE安全读取task_struct字段
bpf_core_read(&pid, sizeof(pid), &task->pid);
bpf_core_read(&tgid, sizeof(tgid), &task->tgid);
u64 ts = bpf_ktime_get_ns();
// key用tgid和pid组合，区分进程与线程
u32 key = tgid;
start.update(&key, &ts);
return 0;
}
TRACEPOINT_PROBE(syscalls, sys_exit_poll)
{
struct task_struct *task = (struct task_struct *)bpf_get_current_task();
u32 tgid = 0;
bpf_core_read(&tgid, sizeof(tgid), &task->tgid);
u64 *tsp = start.lookup(&tgid);
if (tsp == 0)
return 0;
u64 delta = bpf_ktime_get_ns() - *tsp;
u64 *total = latency.lookup_or_try_init(&tgid, &delta);
if (total)
*total += delta;
start.delete(&tgid);
return 0;
}
用户态部分用Python把latency表按tgid读出来，再通过ps或/proc补全进程名，就能得到一张按进程聚合的ppoll等待时长排行。如果想进一步定位到具体的fd，可以在enter探针里读取第二个参数ufds所指向的pollfd数组，用bpf_probe_read_user把fd和events字段拷贝出来，配合bpf_perf_event_output推送到用户态解析。
从等待时长到唤醒来源的进阶分析
只统计等待时长还不够，很多时候我们更想知道进程是被谁唤醒的。这就需要把poll的等待路径串起来看：do_sys_poll最终会走到poll_schedule_timeout，进程在此处睡眠，直到某个fd上的回调函数触发wake_up。可以在sched_wakeup tracepoint上再做一层过滤，配合之前记录的pid，就能得到完整的唤醒时序。
把这些数据按时间轴展开后，一个常见的高精度分析场景就浮出水面了：如果某个线程的ppoll频繁以极短间隔返回，且retval为零，说明超时设置过短导致空转，CPU白白消耗在系统调用上；如果等待时长普遍很长但唤醒后有大量就绪fd，说明并发模型健康；如果唤醒后retval只有一个fd，而该fd对应的对端处理慢，那瓶颈就不在多路复用本身，而在下游服务。
最后提醒一点，tracepoint方案在容器环境下同样有效，因为tracepoint是全局的，只要正确解析pid namespace（通过task_struct里的nsproxy相关字段做映射），就能把容器内进程与宿主机视角对应起来。相比在容器里装监控agent，这种内核态采集的方式侵入性几乎为零，也更适合大规模集群的常态化IO行为画像。掌握了bpf_get_current_task加tracepoint这套组合拳，ppoll、poll乃至select的分析都可以用同一套框架平滑覆盖。
bpf_get_current_taskppolleBPF修改时间：2026-09-03 23:25:11