第2章 Linux内核性能剖析基石

第2章：Linux内核性能剖析基石：Perf工具架构、事件类型与perf list命令详解

各位同学，欢迎来到第二章。上一章我们聊了ADAS系统性能分析的全局图景，今天咱们要深入一个具体工具——Perf。说实话，Perf是我在ADAS项目里用得最频繁的工具，没有之一。它就像一把瑞士军刀，轻巧但功能强大。

为什么Perf这么重要？因为ADAS系统跑在Linux上，而Perf是内核自带的性能剖析工具。你想想看，一个工具能直接访问硬件计数器、内核跟踪点，还不依赖第三方库——这简直是嵌入式开发的福音。我在调试一个车道保持系统的延迟问题时，就是靠Perf定位到某个中断处理函数占用了过多CPU时间。

2.1 Perf工具架构：从用户态到内核态

Perf的架构其实不复杂，但理解它有助于你用好它。说白了，它分三层：

用户态工具：就是我们敲的perf stat、perf record这些命令。它们通过系统调用与内核交互。
内核子系统：perf_event子系统，负责管理事件、采样、缓冲区。这部分是核心。
硬件/软件事件源：PMU（性能监控单元）、内核跟踪点、软件计数器等。

我个人习惯把Perf想象成一个“事件路由器”。用户态告诉内核“我要监控哪些事件”，内核就去收集，然后返回结果。嗯，这里要注意：Perf的采样模式有两种——计数模式和采样模式。计数模式只统计事件次数，采样模式会记录事件发生时的上下文（比如指令地址、调用栈）。

核心要点：Perf的架构设计让它既能做全局统计，也能做局部采样。在ADAS系统中，我通常先用计数模式看整体CPU利用率，再用采样模式定位热点函数。

2.2 事件类型：硬件、软件、跟踪点

Perf支持三类事件，我分别说说。

2.2.1 硬件事件

硬件事件直接来自CPU的PMU。比如：

cpu-cycles：CPU周期数
instructions：执行的指令数
cache-references：缓存访问次数
cache-misses：缓存未命中次数
branch-misses：分支预测失败次数

这些事件非常精确，但依赖具体CPU架构。我在项目中遇到过一个问题：同一个perf命令在ARM Cortex-A72和Cortex-A55上跑，结果差异很大。后来发现是PMU事件映射不同。所以，跨平台对比时要小心。

避坑指南：我曾经在ADAS域控制器上调试性能，发现cache-misses数值异常高。排查了半天，结果是DMA操作和CPU缓存一致性协议冲突。Perf能告诉你“发生了什么”，但“为什么”还得结合硬件手册分析。

2.2.2 软件事件

软件事件由内核生成，不依赖硬件。常见的有：

context-switches：上下文切换次数
cpu-migrations：进程迁移到其他CPU的次数
page-faults：缺页异常次数
task-clock：任务占用的CPU时间

这些事件对ADAS系统特别有用。比如，如果你发现context-switches频繁，说明调度器在忙活，实时性可能受影响。我记得有一次，一个感知算法模块的延迟抖动很大，用perf stat -e context-switches一看，每秒切换上千次——原来是线程优先级设置不合理。

2.2.3 跟踪点事件

跟踪点（tracepoint）是内核静态插桩点，可以监控特定内核函数调用。比如：

sched:sched_switch：任务切换事件
irq:irq_handler_entry：中断处理入口
syscalls:sys_enter_read：系统调用read入口

跟踪点非常灵活，能让你看到内核内部的行为。我个人觉得，这是Perf最强大的功能之一。在ADAS系统中，我常用sched:sched_switch来分析任务调度延迟。

注意事项：跟踪点事件会产生额外开销。如果采样频率太高，反而会影响系统性能。我建议在生产环境中，采样频率不要超过1000Hz。

2.3 perf list命令详解

perf list是Perf的“事件字典”。它能列出当前系统支持的所有事件。用法很简单：

perf list

输出会按类型分组，比如：

List of pre-defined events (to be used in -e):

  cpu-cycles OR cycles                      [Hardware event]
  instructions                              [Hardware event]
  cache-references                          [Hardware event]
  cache-misses                              [Hardware event]
  branch-instructions OR branches           [Hardware event]
  branch-misses                             [Hardware event]
  bus-cycles                                [Hardware event]

  cpu-clock                                 [Software event]
  task-clock                                [Software event]
  page-faults OR faults                     [Software event]
  context-switches OR cs                    [Software event]
  cpu-migrations OR migrations              [Software event]
  minor-faults                              [Software event]
  major-faults                              [Software event]

  alignment-faults                          [Software event]
  emulation-faults                          [Software event]

  L1-dcache-load-misses                     [Hardware cache event]
  L1-dcache-loads                           [Hardware cache event]
  L1-dcache-stores                          [Hardware cache event]
  L1-icache-load-misses                     [Hardware cache event]
  LLC-load-misses                           [Hardware cache event]
  LLC-loads                                 [Hardware cache event]
  dTLB-load-misses                          [Hardware cache event]
  dTLB-loads                                [Hardware cache event]
  iTLB-load-misses                          [Hardware cache event]
  iTLB-loads                                [Hardware cache event]
  branch-loads                              [Hardware cache event]
  branch-load-misses                        [Hardware cache event]

  rNNN                                      [Raw hardware event descriptor]
  cpu/t1=v1[,t2=v2,t3=v3]/                  [Raw hardware event descriptor]
  (see 'man perf-list' on how to encode it)

  mem:<addr>[:<access>]                     [Hardware breakpoint]

  sched:sched_switch                        [Tracepoint event]
  sched:sched_wakeup                        [Tracepoint event]
  sched:sched_wakeup_new                    [Tracepoint event]
  sched:sched_process_fork                  [Tracepoint event]
  sched:sched_process_exec                  [Tracepoint event]
  sched:sched_process_exit                  [Tracepoint event]
  irq:irq_handler_entry                     [Tracepoint event]
  irq:irq_handler_exit                      [Tracepoint event]
  syscalls:sys_enter_read                   [Tracepoint event]
  syscalls:sys_exit_read                    [Tracepoint event]
  ...

你可以用perf list <keyword>来过滤。比如：

perf list sched

只显示调度相关的跟踪点。这个技巧在ADAS调试中很实用——你不需要看几百个事件，只关注跟调度、中断、I/O相关的就行。

实战建议：在ADAS系统上，我通常会先跑perf list看看当前内核支持哪些事件。不同内核版本、不同芯片厂商的Perf事件集可能不一样。比如，有些SoC会添加自定义硬件事件，像“NPU利用率”之类的。这些信息对性能分析很有价值。

2.4 事件选择策略

事件这么多，怎么选？我分享一个经验：

先看CPU利用率：用cycles和instructions算CPI（每指令周期数）。CPI高说明CPU在等待什么（比如内存、I/O）。
再看缓存效率：cache-misses高说明数据局部性差，可能需要优化数据结构。
最后看调度和中断：context-switches和irq跟踪点能帮你定位实时性问题。

举个例子，我在调试一个ADAS摄像头数据流时，发现cache-misses占比很高。用perf record -e cache-misses采样后，发现是图像处理函数中一个循环访问了非连续内存。改成行优先存储后，性能提升了30%。

小技巧：如果你不确定用哪个事件，可以先用perf stat -d跑一下。它会自动选择一组常用事件，包括硬件和软件事件。输出结果会告诉你哪些指标异常。

2.5 本章小结

这一章我们聊了Perf的架构、三类事件类型，以及perf list的使用方法。Perf工具虽然看起来简单，但用好它需要理解底层机制。下一章，我们会深入perf stat和perf record的实战用法，敬请期待。

最后提醒一句：别光看文档，动手跑一下perf list，看看你的系统支持哪些事件。实践出真知。

📚 课程目录