Linux eBPF对堆栈跟踪的支持将使许多新的和令人敬畏的事情成为可能，但是，它并没有进入刚刚发布的 Linux 4.4，它添加了其他 eBPF 特性。设想一些时间在具有 eBPF 但没有堆栈跟踪的旧内核上，我已经开发了一个 hacky 解决方法来做一些很棒的事情。
我将展示我的新密件抄送工具（eBPF 前端），然后解释它是如何工作的。
stackcount：频率计数内核堆栈跟踪
stackcount工具频率计算给定函数的内核堆栈。这是在内核中使用 eBPF 映射来提高效率的。只有唯一的堆栈及其计数被复制到用户级别进行打印。
例如，导致 submit_bio() 的频率计数内核堆栈跟踪：
./stackcount submit_bio
跟踪“submit_bio”的 1 个函数…按 Ctrl-C 结束。
^C
提交_生物
提交_bh
journal_submit_commit_record.isra.13
jbd2_journal_commit_transaction
kjournald2
线程
ret_from_fork
mb_cache_list
1
[…截断…]
提交_生物
提交_bh
jbd2_journal_commit_transaction
kjournald2
线程
ret_from_fork
mb_cache_list
38
提交_生物
ext4_writepages
do_writepages
__filemap_fdatawrite_range
文件映射刷新
ext4_alloc_da_blocks
ext4_rename
ext4_rename2
vfs_rename
sys_rename
entry_SYSCALL_64_fastpath
79
打印堆栈跟踪的顺序是从最少到最频繁。此示例中最频繁的，最后打印的，在跟踪期间被拍摄了 79 次。
最后的堆栈跟踪显示系统调用处理、ext4_rename() 和 filemap_flush()：看起来应用程序发出的文件重命名由于 ext4 块分配和 filemap_flush() 而导致后端磁盘 I/O。
该工具对于探索和研究内核行为非常有用，可以快速回答给定函数的调用方式。
stacksnoop：打印内核堆栈跟踪
stacksnoop工具为每个事件打印内核堆栈跟踪。例如，对于 ext4_sync_fs()：
./stacksnoop -v ext4_sync_fs
TIME(s) COMM PID CPU 堆栈
42005557.056332998 同步 22352 1
42005557.056336999 同步 22352 1 ip: ffffffff81280461 ext4_sync_fs
42005557.056339003 同步 22352 1 r0: ffffffff811ed7f9 iterate_supers
42005557.056340002 同步 22352 1 r1：ffffffff8121ba25 sys_sync
42005557.056340002 sync 22352 1 r2: ffffffff81775cb6 entry_SYSCALL_64_fastpath
42005557.056358002 sync 22352 1
42005557.056358002 sync 22352 1 ip: ffffffff81280461 ext4_sync_fs
42005557.056359001 sync 22352 1 r0: ffffffff811ed7f9 iterate_supers
42005557.056359999 sync 22352 1 r1: ffffffff8121ba35 sys_sync
42005557.056359999 sync 22352 1 r2: ffffffff81775cb6 entry_SYSCALL_64_fastpath
Since the output is verbose, this isn’t suitable for high frequency calls (eg, over 1,000 per second). You can use funccount from bcc tools to measure the rate of a function call, and if it is high, try stackcount instead.
How It Works: Crazy Stuff
eBPF 是一个内核虚拟机，它可以做各种各样的事情，包括“疯狂的事情”。所以我在 eBPF 中编写了一个用户定义的堆栈遍历器，内核可以运行它。以下是来自 stackcount 的相关代码（您不会理解这一点）：
#define 最大深度 10
结构键_t {
u64 ip；
u64 右[MAXDEPTH];
};
BPF_HASH（计数，结构 key_t）；
静态 u64 get_frame(u64 *bp) {
如果（*bp）{
// 以下堆栈遍历器是 x86_64 特定的
u64 右 = 0;
if (bpf_probe_read(&ret, sizeof(ret), (void *)(*bp+8)))
返回0；
if (bpf_probe_read(bp, sizeof(*bp), (void *)*bp))
*bp = 0;
如果 (ret < __START_KERNEL_map)
返回0；
返回正确；
}
返回0；
}
int trace_count(struct pt_regs *ctx) {
筛选
结构 key_t 键 = {};
u64 零 = 0，*val，bp = 0；
整数深度 = 0；
key.ip = ctx->ip;
bp = ctx->bp;
// 展开循环，10 (MAXDEPTH) 帧深：
if (!(key.ret[depth++] = get_frame(&bp))) goto out;
if (!(key.ret[depth++] = get_frame(&bp))) goto out;
if (!(key.ret[depth++] = get_frame(&bp))) goto out;
if (!(key.ret[depth++] = get_frame(&bp))) goto out;
if (!(key.ret[depth++] = get_frame(&bp))) goto out;
if (!(key.ret[depth++] = get_frame(&bp))) goto out;
if (!(key.ret[depth++] = get_frame(&bp))) goto out;
if (!(key.ret[depth++] = get_frame(&bp))) goto out;
if (!(key.ret[depth++] = get_frame(&bp))) goto out;
if (!(key.ret[depth++] = get_frame(&bp))) goto out;
出去：
val = counts.lookup_or_init(&key, &zero);
(*val)++;
返回0；
}
一旦 eBPF 正确支持这一点，上述大部分代码将成为单个函数调用。
如果你好奇：我使用展开的循环遍历每一帧（eBPF 不进行向后跳转），在这种情况下最多十帧。它遍历 RBP 寄存器（基指针）并将每一帧的返回指令指针保存到一个数组中。我不得不使用显式的 bpf_probe_read()s 来取消引用指针（bcc 在某些情况下可以自动执行此操作）。我还在代码中保留了展开的循环（Python 可以生成它）以保持简单，并帮助说明开销。
这个 hack（到目前为止）仅适用于 x86_64、内核模式和有限的堆栈深度。如果我（或您）真的需要更多，请继续进行黑客攻击，但请记住，这只是一种解决方法，直到存在适当的堆栈遍历。
其他解决方案
stackcount 为核心 Linux 内核实现了一项重要的新功能：频率计数堆栈跟踪。像 stacksnoop 一样打印堆栈跟踪已经有很长时间了：ftrace 可以做到这一点，我在perf-tools的kprobe工具中使用它。perf_events还可以转储堆栈跟踪，并具有将打印唯一路径和百分比的报告模式（尽管在用户模式下执行效率较低）。
SystemTap 长期以来一直能够对内核模式和用户模式堆栈跟踪进行频率计数，也在内核中以提高效率，尽管它是一个附加组件而不是主线内核的一部分。
未来的读者
如果您使用的是 Linux 4.5 或更高版本，那么 eBPF 可能会正式支持堆栈遍历。要检查，请在 bpf_func_id 中查找类似 BPF_FUNC_get_stack 的内容。或者查看stackcount等工具的最新源代码——该工具应该仍然存在，但是上面的 stack walker hack 可以用一个简单的调用来代替。
感谢 Brenden Blanco (PLUMgrid) 对这个 hack 的帮助。如果您在SCaLE14x，您可以在周六观看他的IO Visor eBPF 演讲，以及周日我的Broken Linux Performance Tools演讲！
转载翻译自: https://www.brendangregg.com