挂载kprobe与uprobe的eBPF程序性能影响及延迟开销问询

一、开销数值范围 #

kprobe + eBPF #

单次触发的延迟通常在几十纳秒到几百纳秒之间：

• 若eBPF逻辑极简（如仅做计数、读取1-2个寄存器值），开销可低至50-100ns，接近原生内核指令的执行耗时；
• 若eBPF包含复杂逻辑（如哈希表查询/插入、多分支判断），开销会上升至200-500ns，极端复杂场景可能突破1微秒。

uprobe + eBPF #

单次触发开销确实高于kprobe，范围在几百纳秒到几微秒：

• 核心额外开销来自「用户态→内核态」的切换（本身约50-150ns），再加上eBPF程序的执行耗时；
• 若目标用户态函数本身执行时间极短（如仅几纳秒的工具函数），uprobe+eBPF的相对开销会被放大，可能让函数整体耗时翻倍甚至数倍。

二、非显性影响因素 #

除CPU性能、内核版本之外，以下因素会显著影响开销：

• eBPF程序复杂度：这是最关键的变量。大量分支、循环、频繁调用BPF映射操作（如bpf_map_lookup_elem）会大幅增加执行时间；仅做简单数据采集的程序开销可忽略不计。
• 探针触发频率：挂载在高频执行的函数（如内核调度函数schedule、用户态高频工具函数）上时，即使单次开销小，累积的CPU占用也会拉高系统整体延迟。
• 目标函数的执行上下文：若目标函数处于中断上下文，eBPF程序会受更多限制（无法执行阻塞操作），一旦违规会触发内核错误处理，额外增加开销；用户态进程若频繁被调度，uprobe的跨态切换耗时也会变长。
• BPF辅助函数的使用：调用bpf_ktime_get_ns这类轻量辅助函数开销极小，但bpf_trace_printk、bpf_perf_event_output这类需要和用户态交互的函数，会让单次开销飙升至数微秒。
• 系统负载状态：CPU满载时，eBPF程序的JIT编译、执行会遭遇调度延迟，uprobe的跨态切换耗时也会显著增加。
• 探针类型：kretprobe/uretprobe（返回探针）需要保存和恢复更多上下文，开销比普通的kprobe/uprobe高10%-30%左右。

内容的提问来源于stack exchange，提问作者blonded04