From 3fd7b08162cc89c1872e760e7b792acc53b674cd Mon Sep 17 00:00:00 2001 From: LinuxDev9002 Date: Sun, 19 Jul 2026 15:04:29 -0700 Subject: [PATCH] Add fsession feature background --- src/52-fsession-latency/README.md | 4 +++- src/52-fsession-latency/README.zh.md | 4 +++- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/src/52-fsession-latency/README.md b/src/52-fsession-latency/README.md index 4f13b15..5e888c0 100644 --- a/src/52-fsession-latency/README.md +++ b/src/52-fsession-latency/README.md @@ -2,7 +2,9 @@ Suppose a file-backed service shows read-latency spikes. Application timing tells you that requests slowed down, but it cannot distinguish a blocked kernel read path from user-space work. The useful question is: which thread made the read, how many bytes did it request, what did the call return, and how long did that one `vfs_read` invocation take? -This tutorial demonstrates `fsession_latency`, which attaches a single BPF program at `SEC("fsession/vfs_read")`. The program timestamps entry, computes latency at return, and reports only calls that reach or exceed a threshold. Linux 7.0 fsession runs that same BPF program once at function entry and once at function return, providing an 8-byte per-invocation scratch slot via `bpf_session_cookie(ctx)` that replaces the per-thread hash-map insert, lookup, and cleanup commonly used by a separate fentry/fexit pair. +This tutorial is part of the eBPF Tutorial by Example series. The basic model is that user space loads and attaches a verifier-checked tracing program to a kernel function, and the BPF side measures kernel execution and sends selected events back to user space. + +When a tracing scenario needs to observe both function entry and return, the common approach is to write separate fentry and fexit programs and carry the timestamp from entry to return through a per-thread map. Linux 7.0 introduced fsession, which executes one BPF program at both function entry and return and supplies an 8-byte per-invocation session cookie via `bpf_session_cookie(ctx)`. The `fsession_latency` tool in this tutorial uses that capability to timestamp `vfs_read` entry, compute latency at return, filter by TGID and threshold, and report slow reads. > Complete source: diff --git a/src/52-fsession-latency/README.zh.md b/src/52-fsession-latency/README.zh.md index dc9159f..6466f89 100644 --- a/src/52-fsession-latency/README.zh.md +++ b/src/52-fsession-latency/README.zh.md @@ -2,7 +2,9 @@ 假设一个文件服务出现了读延迟尖峰，应用层计时只能告诉你请求变慢了，却无法区分是内核读路径阻塞还是用户态逻辑耗时。有用的问题是：哪个线程发起了读操作、请求了多少字节、调用返回了什么、这一次 `vfs_read` 花了多长时间。 -本教程演示 `fsession_latency`，它将一个 BPF 程序附加到 `SEC("fsession/vfs_read")`，在函数进入时记录时间戳、返回时计算延迟，只上报达到或超过阈值的调用。Linux 7.0 引入的 fsession 让同一个 BPF 程序在被追踪函数的进入和返回阶段各执行一次，通过 `bpf_session_cookie(ctx)` 提供一个 8 字节的调用级暂存区，替代了传统 fentry/fexit 所需的每线程哈希表插入、查找和清理。 +本教程属于 eBPF Tutorial by Example 系列。eBPF 的基本工作方式是：用户空间将一个经过验证器检查的追踪程序加载并附加到内核函数上，BPF 侧测量内核执行过程并将选中的事件发送回用户空间。 + +当一个追踪场景需要同时观察函数进入和返回时，传统做法是编写独立的 fentry 和 fexit 程序，用一个按线程索引的 map 将时间戳从进入传递到返回。Linux 7.0 引入了 fsession，它让同一个 BPF 程序在被追踪函数的进入和返回阶段各执行一次，并通过 `bpf_session_cookie(ctx)` 提供一个 8 字节的调用级暂存区。本教程的 `fsession_latency` 利用这一能力，在 `vfs_read` 进入时记录时间戳、返回时计算延迟，按 TGID 和阈值过滤后上报慢读事件。 > 完整源码：