Linux 内核 ftrace 深度实战：从 function tracer 到生产级 trace 分析的完整链路

2 阅读 0 评论 0 点赞

Linux 内核 ftrace 深度实战：从 function tracer 到生产级 trace 分析的完整链路

ftrace 是 Linux 内核最强大的内置追踪框架之一，它从 2.6.27 内核引入至今，已经成为内核开发者和系统工程师调试性能问题、理解内核行为的首选工具。本文将从 ftrace 的设计哲学出发，深入剖析其底层插桩机制、各种 tracer 的适用场景，并结合真实生产环境案例，展示如何构建零依赖、低开销的全栈可观测方案。

1. ftrace 的设计哲学与架构总览

ftrace（Function Tracer）最初的设计目标是成为一个极低开销的函数调用追踪器。它由 Steven Rostedt 主导开发，核心理念是：用编译器插桩换取运行时灵活性，用 ring buffer 保证数据完整性，用 debugfs/sysfs 提供最小化接口。

ftrace 的架构可以分为四个层次：

插桩层（Instrumentation Layer）：通过 gcc 的 -pg 编译选项或 mcount 机制，在每个函数入口插入nop 指令，运行时动态替换为调用
Tracers 层：function、function_graph、nop、blk、irqsoff、preemptoff 等各种追踪模式
Ring Buffer 层：lock-free 的 per-CPU 环形缓冲区，保证高吞吐低延迟的事件写入
前端接口层：debugfs（tracefs）、trace-cmd、KernelShark、perf ftrace 等用户工具

┌─────────────────────────────────────────────────────┐
│                  用户空间工具                          │
│      trace-cmd │ perf ftrace │ KernelShark           │
├─────────────────────────────────────────────────────┤
│                   tracefs 接口                        │
│  /sys/kernel/debug/tracing/ 或 /sys/kernel/tracing/  │
├─────────────────────────────────────────────────────┤
│                   ftrace 核心                          │
│  插桩管理 │ Tracer 插件 │ Ring Buffer │ Filter/Event  │
├─────────────────────────────────────────────────────┤
│                   内核函数                             │
│  [mcount入口] ──→ [动态ftrace] ──→ [被追踪的函数]    │
└─────────────────────────────────────────────────────┘

2. 底层插桩机制：从 mcount 到动态 ftrace

2.1 mcount 与 fentry

在 x86_64 架构上，ftrace 使用 gcc 的 -pg -mfentry 编译选项，在每个函数入口处插入一个 __fentry__ 调用。这个调用指向一个弱符号，默认情况下是 nop，不会产生任何运行时开销。

ARM64 架构上则使用 -pg -mcount 或直接利用编译器插入的 mcount 调用。现代编译器还支持 -fpatchable-function-entry=N 选项，允许在函数入口前插入 N 个 nop 指令，为运行时 patch 提供更灵活的替换空间。

# x86_64 函数入口（通过 objdump 观察）
0000000000000000 :
   0:   call   __fentry__        ← ftrace 插桩点（5字节）
   5:   push   %rbp
   7:   mov    %rsp,%rbp
   ...

这种设计的巧妙之处在于：当没有 tracer 激活时，这些 nop 指令几乎零开销。x86 的 nop 是单字节指令，一条 call 指令也只有 5 字节，CPU 的流水线可以完全忽略它们。

2.2 动态替换流程

当用户启用 function tracer 时，ftrace 执行以下步骤：

记录所有被插桩函数的地址（编译时保存在 __mcount_loc 段中）
将这些地址维护在一个 hash table 中（ftrace_hash），实现 O(1) 的函数名查找
遍历所有函数入口，将 nop 替换为 call ftrace_caller
通过 stop_machine() 或 text_poke 机制安全地替换指令

这里的关键技术是 stop_machine()：它会让所有 CPU 在一个安全点同步暂停，然后执行指令修改操作，修改完成后恢复执行。这保证了在 SMP 系统中不会出现某条 CPU 在执行旧指令而另一条 CPU 已经开始执行新指令的竞争条件。

2.3 跳板机制（Ftrace Trampoline）

当多个 tracer 同时作用于同一个函数时（例如 function tracer + function_graph tracer），ftrace 不会反复修改原始函数入口，而是使用 跳板机制：

编译时分配一块特殊的内存区域作为跳板池
每个配置了一个 tracer 的函数，有一条跳板代码指向对应的 tracer 处理函数
当移除某个 tracer 时，只需修改跳板的反向指针，无需触碰原始函数代码

这种设计使得 tracer 的开关操作复杂度从 O(N) 下降到 O(1)，极大提升了动态 tracker 的管理效率。

3. Tracer 插件全景

ftrace 支持丰富的 tracer 插件，每种适用于不同的诊断场景：

3.1 function 与 function_graph

function tracer 记录函数被调用的信息（函数名、PID、时间戳），function_graph tracer 更进一步，记录函数的进入和退出，生成完整的调用关系图。

# 启用 function_graph tracer
echo function_graph > /sys/kernel/tracing/current_tracer
echo vfs_read > /sys/kernel/tracing/set_ftrace_filter
echo 1 > /sys/kernel/tracing/tracing_on

# 触发一些 I/O 操作
dd if=/dev/zero of=/tmp/test bs=4k count=1

# 查看结果
cat /sys/kernel/tracing/trace

输出示例：

                                 _----→ ls-1234
                                / _-→  cat-5678
                               |  /                      
  0)   0.000   ls              | |                    
  0)   0.000   ↓ vfs_read     | |                    
  0)   0.001   ↓ ext4_file_read_iter  | |             
  0)   0.003   ↓ generic_file_buffered_read  | |       
  0)   0.004   ↓ filemap_get_pages     | |             
  0)   0.005   ↓ __page_cache_alloc   | |             
  0)   0.006   ↓ alloc_pages     | |             
  0)   0.007   ↑ alloc_pages      0.001 us               
  0)   0.007   ↑ __page_cache_alloc 0.002 us             
  0)   0.008   ↑ filemap_get_pages 0.003 us               
  0)   0.009   ↑ generic_file_buffered_read  0.005 us     
  0)   0.010   ↑ ext4_file_read_iter  0.007 us            
  0)   0.011   ↑ vfs_read      0.009 us

3.2 irqsoff 与 preemptoff

当系统出现实时性问题时，这两个 tracer 是定位延迟源的利器：

irqsoff：追踪中断被关闭的最长时间，记录超过阈值的延迟事件
preemptoff：追踪抢占被关闭的最长时间，帮助发现抢占抑制的热点

在音频处理、工业控制、高频交易等场景中，微秒级的延迟抖动都可能导致严重问题。通过设置阈值过滤，可以仅捕获有诊断价值的事件：

# 捕获中断关闭超过 100μs 的事件
echo irqsoff > /sys/kernel/tracing/current_tracer
echo 100 > /sys/kernel/tracing/tracing_thresh
echo 1 > /sys/kernel/tracing/tracing_on

3.3 wakeup 与 wakeup_dl

wakeup tracer 追踪进程从被唤醒到真正开始运行在 CPU 上的延迟。这对于分析调度延迟（特别是在 CFS 调度器下）非常有价值。wakeup_dl 则专门针对 deadline 调度类。

典型场景：一个实时进程完成 I/O 后从阻塞态被唤醒，但可能需要等待几百微秒才有 CPU 时间片。wakeup tracer 能精确描绘出这段延迟的来源——可能是 CPU 被其他任务占用，也可能是中断处理过长。

4. Tracepoints：语义化的事件接口

如果说 function tracer 追踪的是"哪个函数被调用了"，那么 tracepoint 记录的是"在什么状态点发生了什么有意义的事情"。tracepoint 提供了语义化的事件记录能力。

4.1 Tracepoint 的定义与注册

tracepoint 使用 TRACE_EVENT 宏定义，这个宏展开后生成以下核心结构：

// 以 sched_switch tracepoint 为例
TRACE_EVENT(sched_switch,
    TP_PROTO(struct task_struct *prev, struct task_struct *next),
    TP_ARGS(prev, next),
    TP_STRUCT__entry(
        __array(char, prev_comm, TASK_COMM_LEN)
        __field(pid_t, prev_pid)
        __field(int, prev_prio)
        __field(long, prev_state)
        __array(char, next_comm, TASK_COMM_LEN)
        __field(pid_t, next_pid)
        __field(int, next_prio)
    ),
    TP_fast_assign(
        memcpy(__entry->prev_comm, prev->comm, TASK_COMM_LEN);
        __entry->prev_pid = prev->pid;
        __entry->prev_prio = prev->prio;
        __entry->prev_state = prev->__state;
        memcpy(__entry->next_comm, next->comm, TASK_COMM_LEN);
        __entry->next_pid = next->pid;
        __entry->next_prio = next->prio;
    ),
    TP_printk("prev_comm=%s prev_pid=%d prev_prio=%d prev_state=%s ==> "
              "next_comm=%s next_pid=%d next_prio=%d",
        __entry->prev_comm, __entry->prev_pid, __entry->prev_prio,
        __entry->prev_state ? __print_flags(...) : "R",
        __entry->next_comm, __entry->next_pid, __entry->next_prio)
);

这种定义方式保证了数据格式的二进制稳定性——即使内核版本变化，只要 tracepoint 名称不变，解析工具就能正确读取。

4.2 常用 tracepoint 分类

调度类：sched_switch、sched_waking、sched_wakeup、sched_process_fork/exit
内存类：mm_page_alloc、mm_page_free、kmalloc、kfree
文件类：ext4_sync_file、ext4_da_write_begin、filemap_map_pages
网络类：net_dev_queue、netif_receive_skb、tcp_retransmit_skb
块设备类：block_rq_issue、block_rq_complete、block_bio_queue
syscall 类：sys_enter、sys_exit（wracepoints 自动生成）

5. Filter 与 Event 的高级用法

5.1 函数过滤器语法

ftrace 支持强大的过滤器语法，可以精确控制追踪范围：

# 追踪所有 ext4_* 开头的函数
echo 'ext4_*' > /sys/kernel/tracing/set_ftrace_filter

# 排除某些函数
echo '!ext4_get_inode_loc' >> /sys/kernel/tracing/set_ftrace_filter

# 使用正则表达式匹配
echo 'vfs_*' > /sys/kernel/tracing/set_ftrace_filter
echo '!vfs_?ync*' >> /sys/kernel/tracing/set_ftrace_filter

# 设置 PID 过滤器
echo 1234 > /sys/kernel/tracing/set_ftrace_pid

# 按栈深度过滤（仅追踪函数调用深度 >= 3 的函数）
echo '>=3' > /sys/kernel/tracing/max_depth

5.2 Hist Trigger：事件聚合直方图

Linux 4.6+ 引入了 hist trigger，允许将 tracepoint 中提取的字段进行聚合统计：

# 统计 vfs_read 的延迟分布（单位：us）
echo 'hist:keys=common_pid:vals=hitcount,lat=common_timestamp.usecs-$ts0' \
    > /sys/kernel/tracing/events/syscalls/sys_enter_vfs_read/trigger

# 触发后查看
cat /sys/kernel/tracing/events/syscalls/sys_enter_vfs_read/hist

输出类似：

# event histogram #
# trigger info: hist:keys=common_pid:vals=hitcount,lat:sort=hitcount:size=2048 [active]
{ common_pid: 1234 } hitcount:    42   lat:   3..4=8
                                    lat:   4..5=15
                                    lat:   5..6=12
                                    lat:   6..7=5
                                    lat:   7..8=2

# trigger info: hist:keys=common_pid:vals=hitcount,lat:sort=lat:size=2048 [active]
Totals:
    Hits: 42
    Entries: 6
    Dropped: 0

5.3 Event Trigger：条件触发的联动追踪

event trigger 允许在一个事件发生时自动触发某个动作：

# 当 ext4_file_read_iter 被调用时，自动启动 stacktrace
echo 'stacktrace' > /sys/kernel/tracing/events/ext4/ext4_file_read_iter/trigger

# 当延迟超过阈值时，启用 function tracer 追踪
echo 'hist:keys=lat:vals=hitcount:lat>1000 if func==vfs_read' \
    > /sys/kernel/tracing/events/syscalls/sys_enter_read/trigger

6. Ring Buffer：高吞吐的事件存储引擎

6.1 Per-CPU 环形缓冲区设计

ftrace 使用 per-CPU 的环形缓冲区（ring buffer），核心设计是 lock-free 写入 + page-level 交换：

  CPU 0 buffer:        CPU 1 buffer:
  ┌─────────┐         ┌─────────┐
  │ Page 0  │←─write─ │ Page 0  │
  │ Page 1  │         │ Page 1  │
  │ Page 2  │         │ Page 2  │
  │   ...   │         │   ...   │
  └─────────┘         └─────────┘
    ↑ reader              ↑ reader
  └──── global commit ────┘

每个 CPU 有自己的写入指针，使用 cmpxchg（compare-and-swap）实现无锁的事件预留。写入完成后，通过 commit 操作更新消费者可见的读指针。这种设计避免了 SMP 场景下的锁竞争。

6.2 时间戳与事件格式

ftrace 的事件记录包含：

tsc 时间戳：通过 rdtsc 指令获取 CPU 时间戳计数器，精度达到纳秒级
事件类型 ID：区分不同类型的追踪事件
事件数据：变长结构，根据事件类型解析

ring buffer 支持多种时间戳模式：全局时间戳（global）、基于某个 CPU 时间戳（local）、混合模式（counter），以适应不同精度和开销的需求。

6.3 高效翻页（Copy-Page）

当 ring buffer 满时，ftrace 采用 copy-page 策略而非简单的覆盖：

将当前页的用户空间内容复制到新页
原子地替换页指针
旧页进入慢速路径（由 reader 读取后回收）

这保证了在消费者滞后时不会丢失事件数据，仅增加少量内存拷贝开销。

7. 生产环境实战案例

7.1 案例一：排查系统调用延迟抖动

某业务反馈 P99 延迟偶尔飙升至 100ms+。使用 ftrace 的 sys_enter/sys_exit tracepoint + function_graph 联动追踪：

#!/bin/bash
# setup_trace.sh - 系统性延迟抖动排查

TRACE_DIR="/sys/kernel/tracing"
TARGET_PID=$1

# 清空并重定向输出
echo nop > $TRACE_DIR/current_tracer
echo 0 > $TRACE_DIR/tracing_on

# 启用 sched_wakeup + sched_switch 追踪
echo 1 > $TRACE_DIR/events/sched/sched_wakeup/enable
echo 1 > $TRACE_DIR/events/sched/sched_switch/enable
echo 1 > $TRACE_DIR/events/sched/sched_stat_runtime/enable

# 设置 PID 过滤
echo $TARGET_PID > $TRACE_DIR/set_event_pid

# 启动追踪
echo 1 > $TRACE_DIR/tracing_on

# 采集 30 秒
sleep 30

# 停止并导出
echo 0 > $TRACE_DIR/tracing_on
cat $TRACE_DIR/trace > /tmp/trace_output.txt

# 分析：计算每次唤醒到实际调度的延迟
awk '/sched_wakeup.*pid='$TARGET_PID'/ { wakeup[$4] = $2 }
     /sched_switch.*prev_pid='$TARGET_PID'/ && wakeup[$4] {
         split($2, t, ":")
         delay = (t[1] - wakeup[$4] / 1000000000) * 1000
         if (delay > 10) print "Wakeup delay: " delay "ms at " $2
         delete wakeup[$4]
     }' /tmp/trace_output.txt

结果发现延迟源是一个内核工作队列（kworker）在处理块设备刷新时关中断时间过长，进而通过 irqsooff tracer 定位到具体的磁盘 I/O 路径。

7.2 案例二：内存分配热点追踪

某容器出现 RSS 持续增长，使用 kmalloc tracepoint制作实时分配直方图：

# 按调用栈统计 kmalloc 分配量
echo 'hist:keys=stacktrace:vals=count:size=bytes_alloc:sort=bytes_alloc' \
    > /sys/kernel/tracing/events/kmem/kmalloc/trigger

# 等待足够的事件
sleep 10

# 查看 Top 分配栈
cat /sys/kernel/tracing/events/kmem/kmalloc/hist | head -50

通过分析直方图，快速定位到一个日志库在热路径上频繁分配临时缓冲区，优化为对象池后内存泄漏问题解决。

7.3 案例三：网络包延迟路径分析

微服务间 RTT 异常增高，使用 net_dev_queue + netif_receive_skb 追踪整个网络栈的处理路径：

# 追踪 net 子系统所有事件
echo 1 > /sys/kernel/tracing/events/net/enable
echo 1 > /sys/kernel/tracing/events/sock/enable
echo 1 > /sys/kernel/tracing/events/tcp/enable

# 过滤特定 IP
echo 'orig_saddr == 10.0.1.5' > /sys/kernel/tracing/events/net/netif_rx/filter
echo 1 > /sys/kernel/tracing/events/net/netif_rx/enable

8. trace-cmd：ftrace 的高级封装

trace-cmd 是 ftrace 的全功能前端工具，支持录制、解析、可视化完整工作流：

# 录制 5 秒的系统调用事件
trace-cmd record -e syscalls -p function sleep 5

# 显示 Top 耗时的函数
trace-cmd report --profile

# 检查同步事件延迟
trace-cmd report -l | awk '$NF > 1000 {print}'  # 延迟 > 1us 的事件

# 使用 KernelShark 可视化
trace-cmd record -p function_graph -g vfs_read my_workload
kernelshark trace.dat &

--profile 选项可以生成函数调用的性能分析报告，类似于 perf top，但基于 function_graph 的精确调用图数据，能展示各层级函数的累计时间和调用次数。

9. 性能开销与最佳实践

9.1 开销数据

实测 ftrace 在不同模式下的性能开销：

nop 模式（未激活）：约 1-3% 编译膨胀，运行时开销 < 0>
function tracer：记录入口，额外开销约 100-300ns/函数调用
function_graph tracer：记录入口+出口，额外开销约 400-800ns/函数调用
tracepoint：未启用时接近零开销（通过 static key 动态启用），启用时约 50-100ns
ring buffer 写入：约 200-500ns/事件

9.2 生产环境部署建议

避免全量追踪：始终使用 filter 限定范围，全量 function_graph 可能带来 10-30% 开销并快速填满 ring buffer
合理设置 buffer 大小：默认 buffer 通常太小，建议根据事件频率调整 buffer_size_kb
使用 snapshot 模式：对于偶发性问题，开启 snapshot 模式，仅在触发条件时抓取，平时只保留最后 N 秒数据
配合 eBPF 使用：ftrace 作为静态插桩的"探针"，eBPF 作为动态"消费者"，两者结合发挥最大价值
避免 tracepoint 命名冲突：内核升级时检查 tracepoint 名称变化，避免解析脚本失效

10. 与 eBPF 的协同：现代可观测栈

ftrace 和 eBPF 并非替代关系，而是互补的。ftrace 的优势在于全覆盖的函数级插桩和极低的基础开销，eBPF 的优势在于动态可编程和灵活的数据处理。

现代可观测架构的分层：

┌──────────────────────────────────────────────────────────┐
│              用户空间分析 / 可视化                          │
│      Grafana │ Jaeger │ custom tools                      │
├──────────────────────────────────────────────────────────┤
│              eBPF 探针层                                    │
│      BCC │ libbpf │ bpftrace │ perf-bench                 │
├──────────────────────────────────────────────────────────┤
│              内核插桩层                                     │
│      ftrace function │ tracepoint │ kprobe │ kretprobe     │
├──────────────────────────────────────────────────────────┤
│              硬件事件层                                     │
│      PMU perf │ breakpoint │ NMI watchdog                 │
└──────────────────────────────────────────────────────────┘

一个典型的协同场景是：使用 function tracer 快速定位函数调用异常（例如某个函数从未被调用），然后用 eBPF 在 kprobe 点提取参数数据，通过 perf buffer 流式传输到用户空间分析。

在新版内核（5.10+）中，ftrace 直接提供了对 BPF 程序的支持（fentry/fexit 挂载点），使得 BPF 程序可以直接作为 ftrace 的 tracer 运行，进一步降低了 BPF 追踪的门槛。

11. 内核 6.x 中的演进

Linus Torvalds 在 Linux 6.x 内核中对 ftrace 做了多项改进：

缩短动态替换时间：通过 per-trampoline 缓存减少了 stop_machine() 的使用
增强的 error injection：在 tracepoint 路径上支持错误注入，方便故障模拟测试
fprobe（Function-based probe）：基于 ftrace 的轻量级探针接口，性能优于传统 kprobe，适合高频函数追踪
BPF trampoline 改进：支持直接调用 BPF 函数的 trampoline，减少间接跳转开销

fprobe 的实现尤为值得关注：它复用 ftrace 的 mcount 插桩机制，用户只需指定函数名即可注册进入/退出回调，无需编写复杂的 BPF 代码或解析 kallsyms。在性能方面，fprobe 由于避免了 kprobe 的 breakpoint/trap 机制，开销可再降低 30-50%。

总结

ftrace 作为 Linux 内核最成熟的追踪框架，其设计哲学值得每一位系统工程师深入理解：

编译时插桩 + 运行时 patch：实现了零依赖的追踪能力，无需额外模块或第三方工具
分层的 tracer 架构：从简单的函数名记录到复杂的调用图分析，各取所需
lock-free ring buffer：per-CPU 设计 + cmpxchg 原子操作，保证高并发下的数据完整性
与 eBPF 的无缝协同：静态插桩与动态可编程的结合，构成了现代内核可观测性的完整图景

对于从事 Linux 系统开发的工程师而言，掌握 ftrace 不仅有助于日常问题排查，更是理解内核调度、内存、I/O 子系统行为模式的窗口。下次当系统出现神秘的延迟抖动或性能问题时，不妨从 /sys/kernel/tracing/ 开始你的排查之路。

点赞(0) 打赏

本文分类：系统工具
本文标签：ftrace Linux 内核追踪性能分析
浏览次数：2 次浏览
发布日期：2026-10-09 07:13:13
本文链接：https://www.ybb.press/system-tools/16192.html

上一篇 > High Sign - Increase Productivity Using Mouse Gestures - Home

Linux 内核 ftrace 深度实战：从 function tracer 到生产级 trace 分析的完整链路

Linux 内核 ftrace 深度实战：从 function tracer 到生产级 trace 分析的完整链路

1. ftrace 的设计哲学与架构总览

2. 底层插桩机制：从 mcount 到动态 ftrace

2.1 mcount 与 fentry

2.2 动态替换流程

2.3 跳板机制（Ftrace Trampoline）

3. Tracer 插件全景

3.1 function 与 function_graph

3.2 irqsoff 与 preemptoff

3.3 wakeup 与 wakeup_dl

4. Tracepoints：语义化的事件接口

4.1 Tracepoint 的定义与注册

4.2 常用 tracepoint 分类

5. Filter 与 Event 的高级用法

5.1 函数过滤器语法

5.2 Hist Trigger：事件聚合直方图

5.3 Event Trigger：条件触发的联动追踪

6. Ring Buffer：高吞吐的事件存储引擎

6.1 Per-CPU 环形缓冲区设计

6.2 时间戳与事件格式

6.3 高效翻页（Copy-Page）

7. 生产环境实战案例

7.1 案例一：排查系统调用延迟抖动

7.2 案例二：内存分配热点追踪

7.3 案例三：网络包延迟路径分析

8. trace-cmd：ftrace 的高级封装

9. 性能开销与最佳实践

9.1 开销数据

9.2 生产环境部署建议

10. 与 eBPF 的协同：现代可观测栈

11. 内核 6.x 中的演进

总结

评论列表共有 0 条评论

发表评论取消回复

Linux 内核 ftrace 深度实战：从 function tracer 到生产级 trace 分析的完整链路

Linux 内核 ftrace 深度实战：从 function tracer 到生产级 trace 分析的完整链路

1. ftrace 的设计哲学与架构总览

2. 底层插桩机制：从 mcount 到动态 ftrace

2.1 mcount 与 __fentry__

2.2 动态替换流程

2.3 跳板机制（Ftrace Trampoline）

3. Tracer 插件全景

3.1 function 与 function_graph

3.2 irqsoff 与 preemptoff

3.3 wakeup 与 wakeup_dl

4. Tracepoints：语义化的事件接口

4.1 Tracepoint 的定义与注册

4.2 常用 tracepoint 分类

5. Filter 与 Event 的高级用法

5.1 函数过滤器语法

5.2 Hist Trigger：事件聚合直方图

5.3 Event Trigger：条件触发的联动追踪

6. Ring Buffer：高吞吐的事件存储引擎

6.1 Per-CPU 环形缓冲区设计

6.2 时间戳与事件格式

6.3 高效翻页（Copy-Page）

7. 生产环境实战案例

7.1 案例一：排查系统调用延迟抖动

7.2 案例二：内存分配热点追踪

7.3 案例三：网络包延迟路径分析

8. trace-cmd：ftrace 的高级封装

9. 性能开销与最佳实践

9.1 开销数据

9.2 生产环境部署建议

10. 与 eBPF 的协同：现代可观测栈

11. 内核 6.x 中的演进

总结

Linux 内核进程调度器深度实战：从 CFS 到 EEVDF 的演进与调优全指南

Linux 内核内存管理深度剖析：从物理页框到虚拟地址空间

Linux 内核进程调度器深度剖析：从 CFS 到 EEVDF 的演进之路

Linux 内核 ftrace 深度实战：从 function tracer 到生产级 trace 分析的完整链路

评论列表 共有 0 条评论

发表评论 取消回复

2.1 mcount 与 fentry

评论列表共有 0 条评论

发表评论取消回复