LWN：用户空间trace event合入一年之后……

关注了就能看到更多这么棒的文章哦～

User trace events, one year later

By Jonathan Corbet
April 3, 2023
DeepL assisted translation
https://lwn.net/Articles/927595/

内核有一套完善的机制来控制对内核空间各种 event 的追踪（tracing）。开发者经常希望能够使用同样的接口来对用户空间的活动进行追踪，但是还没有什么比较好的支持。一年前，有人试图添加控制用户空间跟踪事件的 API，但是没能成功，一直没有被完全启用起来。现在，Beau Belgrave 带着重新设计的 API 回来了，这可能最终可以使得这个机制能广泛使用起来。

用户空间的 trace event 就跟内核中的 event 一样，在大多数时候都是没有打开的；没有人在监听这些事件，所以不应该产生数据。在内核中，这些未激活的 tracepoint 在二进制文件中会直接修改来取消掉，但这种运行时大 patch 的做法在用户空间中并不容易实现。因此，用户空间的代码必须真的要去检查指定的 trace event 是否被启用了，如果启用了就产生相应的数据记录。由于大多数情况下指定 event 应该都是没有启用的，所以这种检查必须要尽可能地快。

在 2022 年，Belgrave 提出的 API 要求程序用 mmap() 将一个特殊的 page 来映射到他们的地址空间。每一个在内核中注册的 event 都会在这个映射出来的 page 中分配一个字节；每当一个 event 被启用时，内核会在相应的字节中存储一个非零值。然后程序可以在 tracepoint 触发时检查该字节，从而确定是否应该产生 tracing data。

人们对这个 API 有一些抱怨。使用整个字节来存储一个 bit 的信息有些浪费。损失 7 个 bit 的内存似乎并不是一个沉重的代价，但真正的问题在于 cache 利用率方面的损失。对每个 event 使用一个 bit 就可以使存储在 cache line 中的 event flag 的数量增加到 8 倍。由于这些 flag 会在程序的最繁忙的代码执行路径中也可能会需要频繁检查，所以 cache 的效率会对支持 tracing 引入的整体开销产生重大影响。此外由于需要对单个 page 进行映射，也不利于那些可能跟所链接的程序独立的 tracing 库文件的情况。

这些抱怨是在开发过程后期出现的，在代码被合入 tracing tree 之后。尽管有这些批评，这些 patch 还是进入了 5.18 版本的内核，但是整个机制在内核配置系统中被标记为 "broken"。因此，user-event 接口在默认情况下是不启用的，而且现在大多数内核都没有缺省打开。

新的 API 完全取消了这个 page mapping 的需求。在希望向内核注册一个 event 时，相应的程序应该打开/sys/kernel/tracing/user_events_data，并发出 DIAG_IOCSREG ioctl()调用，将下面的结构作为参数传递进去：

struct user_reg {
  __u32 size;
  __u8 enable_bit;
  __u8 enable_size;
  __u16 flags;
  __u64 enable_addr;
  __u64 name_args;
  __u32 write_index;
};

user_reg 结构本身的 size 应该被存储在 size 成员变量中；这就可以让内核在今后需要增加这个结构内容的时候保持向后兼容。ioctl()调用将在 enable_addr 地址来注册一个长度为 enable_size 字节的内容；在 64 位系统中，这个 size 必须是 4 或 8 字节。该值中控制 event 的 bit 由 enable_bit 来指定；每当 event 被激活或停用时，内核就会 set 或 clear 这个 bit（而不干扰其他 bit）。flags 值应该是 0，name_args 指向一个字符串，描述 trace event 使用相应 format 所返回的数据。

注册成功后，内核将把一个值存入 write_index，每当程序为指定 event 生成数据时都应该使用这个值。还有一个操作（DIAG_IOCSUNREG），可以用来取消 event 的注册。

新的 API 可以让启用这些 event 的 bit 打包得更密集一些，如果应用程序关注到这一点的话。否则的话，也可以把每个 bit 都放到独立的数据当中，而每个数据中的其他 bit 可以用于其他目的，也许可以由 user-space tracer 来自定义使用。这样就得到了一个更灵活的 API，如果顺利得话就可以解决针对其前身的批评。

到目前为止，这项工作已经进行了第十次修订；过去几轮修订只带来了相对较小的改动。这表明 review 人员对目前的 API 很满意。这项工作似乎准备在 6.4 合并窗口期间推到 upstream 去，并同时提供一个 patch，指出新的 API "似乎在不使用水晶球（crystal ball）的情况下也会很稳定"，并最终从配置选项中删除了 "broken" 标记。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～