perf 在内核代码开发上的应用(1)

perf 在内核代码开发上的应用(1)

之前在《Perf Event ：Linux下的系统性能调优工具》中介绍了 perf 最常见的一些用法，以及Linux 系统上应用程序的调优。本文将把目光转移到内核以及其他 perf 命令上面来。

在内核方面，人们的兴趣五花八门，有些内核开发人员热衷于寻找整个内核中的热点代码;另一些则只关注某一个主题，比如 slab 分配器，对于其余部分则不感兴趣。对这些人而言，perf 的一些奇怪用法更受欢迎。当然，诸如 perf top，perf stat, perf record 等也是内核调优的基本手段，但用法和 part1 所描述的一样，无需重述。

此外虽然内核事件对应用程序开发人员而言有些陌生，但一旦了解，对应用程序的调优也很有帮助。我曾经参与开发过一个数据库应用程序，其效率很低。通过常规的热点查询，IO 统计等方法，我们找到了一些可以优化的地方，以至于将程序的效率提高了几倍。可惜对于拥有海量数据的用户，其运行时间依然无法达到要求。进一步调优需要更加详细的统计信息，可惜本人经验有限，实在是无计可施。。。从客户反馈来看，该应用的使用频率很低。作为一个程序员，为此我时常心情沮丧。。。

假如有 perf，那么我想我可以用它来验证自己的一些猜测，比如是否太多的系统调用，或者系统中的进程切换太频繁 ? 针对这些怀疑使用 perf 都可以拿出有用的报告，或许能找到问题吧。但过去的便无可弥补，时光不会倒流，无论我如何伤感，世界绝不会以我的意志为转移。所以我们好好学习 perf，或许可以预防某些遗憾吧。

这里我还要提醒读者注意，讲述 perf 的命令和语法容易，但说明什么时候使用这些命令，或者说明怎样解决实际问题则很困难。就好象说明电子琴上 88 个琴键的唱名很容易，但想说明如何弹奏动听的曲子则很难。

在简述每个命令语法的同时，我试图通过一些示例来说明这些命令的使用场景，但这只能是一种微薄的努力。因此总体说来，本文只能充当那本随同电子琴一起发售的使用说明书。。。

使用 tracepoint

当 perf 根据 tick 时间点进行采样后，人们便能够得到内核代码中的 hot spot。那什么时候需要使用 tracepoint 来采样呢?

我想人们使用 tracepoint 的基本需求是对内核的运行时行为的关心，如前所述，有些内核开发人员需要专注于特定的子系统，比如内存管理模块。这便需要统计相关内核函数的运行情况。另外，内核行为对应用程序性能的影响也是不容忽视的：

以之前的遗憾为例，假如时光倒流，我想我要做的是统计该应用程序运行期间究竟发生了多少次系统调用。在哪里发生的?

下面我用 ls 命令来演示 sys_enter 这个 tracepoint 的使用：

[root@ovispoly /]# perf stat -e raw_syscalls:sys_enter ls
bin dbg etc lib media opt root
selinux sys usr
boot dev home lost+found mnt proc sbin srv
tmp var
Performance counter stats for 'ls':
101 raw_syscalls:sys_enter
0.003434730 seconds time elapsed
[root@ovispoly /]# perf record -e raw_syscalls:sys_enter ls
[root@ovispoly /]# perf report
Failed to open .lib/ld-2.12.so, continuing without symbols
# Samples: 70
#
# Overhead Command Shared Object Symbol
# ........ ............... ............... ......
#
97.14% ls ld-2.12.so [.] 0x0000000001629d
2.86% ls [vdso] [.] 0x00000000421424
#
# (For a higher level overview, try: perf report --sort comm,dso)
#

这个报告详细说明了在 ls 运行期间发生了多少次系统调用 ( 上例中有 101 次 )，多数系统调用都发生在哪些地方 (97% 都发生在 ld-2.12.so 中 )。

有了这个报告，或许我能够发现更多可以调优的地方。比如函数 foo() 中发生了过多的系统调用，那么我就可以思考是否有办法减少其中有些不必要的系统调用。

您可能会说 strace 也可以做同样事情啊，的确，统计系统调用这件事完全可以用 strace 完成，但 perf 还可以干些别的，您所需要的就是修改 -e 选项后的字符串。

罗列 tracepoint 实在是不太地道，本文当然不会这么做。但学习每一个 tracepoint 是有意义的，类似背单词之于学习英语一样，是一项缓慢痛苦却不得不做的事情。

perf probe

tracepoint 是静态检查点，意思是一旦它在哪里，便一直在那里了，您想让它移动一步也是不可能的。内核代码有多少行?我不知道，100 万行是至少的吧，但目前 tracepoint 有多少呢?我最大胆的想象是不超过 1000 个。所以能够动态地在想查看的地方插入动态监测点的意义是不言而喻的。

Perf 并不是第一个提供这个功能的软件，systemTap 早就实现了。但假若您不选择 RedHat 的发行版的话，安装 systemTap 并不是件轻松愉快的事情。perf 是内核代码包的一部分，所以使用和维护都非常方便。

我使用的 Linux 版本为 2.6.33。因此您自己做实验时命令参数有可能不同。

[root@ovispoly perftest]# perf probe schedule:12 cpu
Added new event:
probe:schedule (on schedule+52 with cpu)
You can now use it on all perf tools, such as:
perf record -e probe:schedule -a sleep 1
[root@ovispoly perftest]# perf record -e probe:schedule -a sleep 1
Error, output file perf.data exists, use -A to append or -f to overwrite.
[root@ovispoly perftest]# perf record -f -e probe:schedule -a sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.270 MB perf.data (~11811 samples) ]
[root@ovispoly perftest]# perf report
# Samples: 40
#
# Overhead Command Shared Object Symbol
# ........ ............... ................. ......
#
57.50% init 0 [k] 0000000000000000
30.00% firefox [vdso] [.] 0x0000000029c424
5.00% sleep [vdso] [.] 0x00000000ca7424
5.00% perf.2.6.33.3-8 [vdso] [.] 0x00000000ca7424
2.50% ksoftirqd/0 [kernel] [k] 0000000000000000
#
# (For a higher level overview, try: perf report --sort comm,dso)
#

上例利用 probe 命令在内核函数 schedule() 的第 12 行处加入了一个动态 probe 点，和 tracepoint 的功能一样，内核一旦运行到该 probe 点时，便会通知 perf。可以理解为动态增加了一个新的 tracepoint。

此后便可以用 record 命令的 -e 选项选择该 probe 点，最后用 perf report 查看报表。如何解读该报表便是见仁见智了，既然您在 shcedule() 的第 12 行加入了 probe 点，想必您知道自己为什么要统计它吧?