eBPF通过sched_switch tracepoint捕获进程级上下文切换事件，记录源/目标进程、CPU、时间戳及voluntary/nonvoluntary原因；需用tgid聚合Golang进程统计，过滤idle任务，并结合sched_stat_sleep等事件反推自愿性，不可依赖pid或截断的comm字段。
用eBPF捕获进程级上下文切换事件：别只盯着sched_switch
eBPF本身不直接提供“上下文切换开销”的数值，它能做的，是精准捕获每次切换的触发点、源进程、目标进程、CPU、时间戳，以及关键上下文（比如是否因voluntary或nonvoluntary原因）。真正的“开销”需要你结合这些事件做差值计算和归因。最常用且稳定的入口是sched:sched_switch tracepoint，而不是kprobe on __schedule——后者在内核版本迭代中容易因符号变更或inline优化失效。
注意：sched_switch每发生一次就记录一条，但单次切换耗时极短（纳秒级），eBPF无法测量单次延迟；你需要统计单位时间内的频次，并关联到具体Golang进程（通过pid、tgid、comm字段）。
- 必须过滤掉idle任务（
comm == "swapper/0"等），否则会严重污染Golang进程的统计 - Golang的goroutine调度发生在用户态，
sched_switch只反映OS线程（M）级别的切换，不是goroutine切换——这点常被误读 - 若想区分自愿/非自愿，需额外挂载
sched:sched_stat_sleep和sched:sched_stat_runtime，从睡眠时长反推voluntary行为
如何把eBPF数据对齐到Go进程：靠tgid + pid + comm三元组
Golang二进制运行后，一个进程可能对应多个线程（ps -T -p $PID可见），而每个线程在sched_switch事件里都有独立的pid。真正代表“Go应用”的是线程组ID（tgid），也就是主goroutine所在OS线程的PID。所以聚合统计时，务必用tgid作为进程标识，而非pid。
comm字段（如"myapp"）可辅助验证，但不可依赖——它可能被截断（15字符限制），且同一tgid下所有线程共享相同comm。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 在eBPF程序里，用
bpf_get_current_pid_tgid()获取u64 val = tgid ，再用右移提取<code>tgid - 用户空间读取ringbuf时，按
tgid分桶计数，避免把worker thread的切换算成“主进程开销” - 不要尝试用
/proc/$PID/cmdline实时查进程名——eBPF不能调用用户空间函数，且该路径在切换瞬间可能已变化
为什么vmstat 1里的cs值和eBPF统计不一致？
vmstat的cs是内核全局计数器，包含中断上下文切换、软中断、timer tick引发的调度等所有类型；而eBPF的sched_switch只统计进程/线程级的主动调度切换。两者本就不该相等，差异大反而说明你没漏掉关键路径。
典型偏差来源：
- 硬中断（如网卡收包）触发的softirq上下文切换，不会触发
sched_switch，但会计入vmstat cs - Golang runtime的
netpoll机制在epoll_wait返回后直接唤醒goroutine，不经过OS调度器，因此无sched_switch事件 - 频繁
nanosleep或epoll_wait超时导致的voluntary切换，在eBPF里体现为高sched_stat_sleep，但vmstat cs只计数，不分原因
真实场景下的性能归因：结合/proc/$PID/status看voluntary_ctxt_switches和nonvoluntary_ctxt_switches
eBPF给你的是微观事件流，而/proc/$PID/status里的两个字段是宏观累计值，它们之间能交叉验证。如果eBPF统计的tgid切换次数远高于nonvoluntary_ctxt_switches，说明大量切换是Go runtime主动让出（比如channel阻塞、runtime.Gosched()），属于应用逻辑问题；反之，若eBPF频次≈nonvoluntary_ctxt_switches，则大概率是CPU争抢或负载过高。
操作建议：
- 在采集eBPF数据前，先记下
cat /proc/$PID/status | grep ctxt的初始值 - 运行30秒eBPF程序，再读一次该值，差值应与eBPF按
tgid聚合的sched_switch次数在同一量级（允许±5%误差） - 若偏差超过20%，检查是否漏了
filter out idle、是否用了pid而非tgid聚合、或内核tracepoint是否被disable（cat /sys/kernel/debug/tracing/events/sched/sched_switch/enable应为1）
最易被忽略的一点：Golang进程的上下文切换开销，本质是OS线程（M）与内核调度器的交互成本，和goroutine数量无直接关系；但goroutine阻塞模式（如sync.Mutex争抢、系统调用阻塞）会显著放大M的切换频次。盯住tgid和nonvoluntary_ctxt_switches的同步增长，才是定位根因的关键。
