1. 布景常识
1.1 与功用调优相关的硬件特性
硬件特性之cache
内存读写是很快的，但仍是无法和处理器的指令履行速度比较。为了从内存中读取指令和数据，处理器需求等候，用处理器的时刻来衡量，这种等候十分绵长。Cache 是一种 SRAM，它的读写速率十分快，能和处理器处理速度相匹配。因此将常用的数据保存在 cache 中，处理器便无须等候，然后进步功用。Cache 的尺度一般都很小，充分运用 cache 是软件调优十分重要的部分。
硬件特性之流水线，超标量体系结构，乱序履行
进步功用最有用的办法之一便是并行。处理器在硬件规划时也尽或许地并行，比方流水线，超标量体系结构以及乱序履行。
处理器处理一条指令需求分多个进程完结，比方先取指令，然后完结运算，最终将核算成果输出到总线上。第一条指令在运算时，第二条指令现已在取指了;而第一条指令输出成果时，第二条指令则又能够运算了，而第三天指令也现已取指了。这样从长时刻看来，像是三条指令在一起履行。在处理器内部，这能够看作一个三级流水线。
超标量（superscalar）指一个时钟周期发射多条指令的流水线机器架构，比方 Intel 的 Pentium 处理器，内部有两个履行单元，在一个时钟周期内答应履行两条指令。
在处理器内部，不同指令所需求的处理进程和时钟周期是不同的，假定严厉依照程序的履行次序履行，那么就无法充分运用处理器的流水线。因此指令有或许被乱序履行。
上述三种并行技能对所履行的指令有一个根本要求，即相邻的指令彼此没有依靠联系。假定某条指令需求依靠前面一条指令的履行成果数据，那么 pipeline 便失掉效果，由于第二条指令有必要等候第一条指令完结。因此好的软件有必要尽量防止这种代码的生成。
硬件特性之分支猜测
分支指令对软件功用有比较大的影响。特别是当处理器选用流水线规划之后，假定流水线有三级，其时进入流水的第一条指令为分支指令。假定处理器次序读取指令，那么假定分支的成果是跳转到其他指令，那么被处理器流水线预取的后续两条指令都将被抛弃，然后影响功用。为此，许多处理器都供给了分支猜测功用，依据同一条指令的前史履行记载进行猜测，读取最或许的下一条指令，而并非次序读取指令。
分支猜测对软件结构有一些要求，关于重复性的分支指令序列，分支猜测硬件能得到较好的猜测成果，而关于相似 switch case 一类的程序结构，则往往无法得到抱负的猜测成果。
上面介绍的几种处理器特性对软件的功用有很大的影响，但是依靠时钟进行定时采样的 profiler 形式无法提醒程序对这些处理器硬件特性的运用状况。处理器厂商针对这种状况，在硬件中参加了 PMU 单元，即 performance monitor unit。PMU 答应软件针对某种硬件作业设置 counter，尔后处理器便开端核算该作业的发生次数，当发生的次数超越 counter 内设置的值后，便发生中止。比方 cache miss 到达某个值后，PMU 便能发生相应的中止。
捕获这些中止，便能够调查程序对这些硬件特性的运用功率了。
1.2 Tracepoints
Tracepoint 是散落在内核源代码中的一些 hook，一旦使能，它们便能够在特定的代码被运转届时被触发，这一特功用够被各种 trace/debug 东西所运用。Perf 便是该特性的用户之一。
假定您想知道在运用程序运转期间，内核内存办理模块的行为，便能够运用潜伏在 slab 分配器中的 tracepoint。当内核运转到这些 tracepoint 时，便会告知 perf。Perf 将 tracepoint 发生的作业记载下来，生成陈述，经过剖析这些陈述，调优人员便能够了解程序运转时期内核的种种细节，对功用症状作出更精确确实诊。
2.Perf简介
Perf是Linux内核自带的体系功用优化东西，原理是：
CPU的PMU registers中Get/Set performance counters来取得比方instrucTIons executed, cache-missed suffered, branches mispredicted等信息。linux kernel对这些registers进行了一系列笼统，所以你能够按进程，按CPU或许按counter group等不同类别来检查Sample信息。
经过Perf，运用程序能够运用 PMU，tracepoint 和内核中的特别计数器来进行功用核算。它不但能够剖析指定运用程序的功用问题 (per thread)，也能够用来剖析内核的功用问题，当然也能够一起剖析运用代码和内核，然后全面了解运用程序中的功用瓶颈。
Perf 不只能够用于运用程序的功用核算剖析，也能够运用于内核代码的功用核算和剖析。得益于其优异的体系结构规划，越来越多的新功用被参加 Perf，使其现已成为一个多功用的功用核算东西集 。
3.perf 的根本运用
功用调优东西如 perf，Oprofile 等的根本原理都是对被监测方针进行采样，最简略的景象是依据 TIck 中止进行采样，即在 TIck 中止内触发采样点，在采样点里判别程序其时的上下文。假定一个程序 90% 的时刻都花费在函数 foo() 上，那么 90% 的采样点都应该落在函数 foo() 的上下文中。命运不可捉摸，但我想只需采样频率满足高，采样时刻满足长，那么以上推论就比较牢靠。因此，经过 TIck 触发采样，咱们便能够了解程序中哪些当地最耗时刻，然后要点剖析。略微扩展一下思路，就能够发现改动采样的触发条件使得咱们能够取得不同的核算数据：以时刻点 ( 如 tick) 作为作业触发采样便能够获悉程序运转时刻的散布。以 cache miss 作业触发采样便能够知道 cache miss 的散布，即 cache 失效常常发生在哪些程序代码中。如此等等。
因此让咱们先来了解一下 perf 中能够触发采样的作业有哪些。
3.1 Perf list，perf 作业
运用 perf list 指令能够列出一切能够触发 perf 采样点的作业。比方 # perf list List of pre-defined events (to be used in -e): cpu-cycles OR cycles [Hardware event] instructions [Hardware event] … cpu-clock [Software event] task-clock [Software event] context-switches OR cs [Software event] … ext4:ext4_allocate_inode [Tracepoint event] kmem:kmalloc [Tracepoint event] module:module_load [Tracepoint event] workqueue:workqueue_execution [Tracepoint event] sched:sched_{wakeup,switch} [Tracepoint event] syscalls:sys_{enter,exit}_epoll_wait [Tracepoint event] …不同的体系会列出不同的成果，在 2.6.35 版其他内核中，该列表现已适当的长，但不管有多少，咱们能够将它们划分为三类：
Hardware Event 是由 PMU 硬件发生的作业，比方 cache 射中，当您需求了解程序对硬件特性的运用状况时，便需求对这些作业进行采样；
Software Event 是内核软件发生的作业，比方进程切换，tick 数等 ;
Tracepoint event 是内核中的静态 tracepoint 所触发的作业，这些 tracepoint 用来判别程序运转期间内核的行为细节，比方 slab 分配器的分配次数等。
上述每一个作业都能够用于采样，并生成一项核算数据，时至今日，尚没有文档对每一个 event 的意义进行具体解说。
3.2 Perf stat
面临一个问题程序，最好选用自顶向下的战略。先全体看看该程序运转时各种核算作业的大约，再针对某些方向深化细节。而不要一会儿扎进琐碎细节，会一叶障意图。
有些程序慢是由于核算量太大，其大都时刻都应该在运用 CPU 进行核算，这叫做 CPU bound 型；有些程序慢是由于过多的 IO，这种时分其 CPU 运用率应该不高，这叫做 IO bound 型；关于 CPU bound 程序的调优和 IO bound 的调优是不同的。
假定您认同这些说法的话，Perf stat 应该是您最早运用的一个东西。它经过归纳精简的办法供给被调试程序运转的全体状况和汇总数据。
下面演示了 perf stat 针对程序 t1 的输出：
$perf stat ./t1 Performance counter stats for './t1':
262.738415 task-clock-msecs # 0.991 CPUs 2 context-switches # 0.000 M/sec 1 CPU-migrations # 0.000 M/sec 81 page-faults # 0.000 M/sec 9478851 cycles # 36.077 M/sec (scaled from 98.24%) 6771 instructions # 0.001 IPC (scaled from 98.99%) 111114049 branches # 422.908 M/sec (scaled from 99.37%) 8495 branch-misses # 0.008 % (scaled from 95.91%) 12152161 cache-references # 46.252 M/sec (scaled from 96.16%) 7245338 cache-misses # 27.576 M/sec (scaled from 95.49%) 0.265238069 seconds time elapsed
上面告知咱们，程序 t1 是一个 CPU bound 型，由于 task-clock-msecs 挨近 1。
对 t1 进行调优应该要找到热门 ( 即最耗时的代码片段 )，再看看是否能够进步热门代码的功率。
缺省状况下，除了 task-clock-msecs 之外，perf stat 还给出了其他几个最常用的核算信息：
Task-clock-msecs：CPU 运用率，该值高，阐明程序的大都时刻花费在 CPU 核算上而非 IO。 Context-switches：进程切换次数，记载了程序运转进程中发生了多少次进程切换，频频的进程切换是应该防止的。 Cache-misses：程序运转进程中全体的 cache 运用状况，假定该值过高，阐明程序的 cache 运用欠好 CPU-migrations：表明进程 t1 运转进程中发生了多少次 CPU 搬迁，即被调度器从一个 CPU 转移到其他一个 CPU 上运转。 Cycles：处理器时钟，一条机器指令或许需求多个 cycles， Instructions: 机器指令数目。 IPC：是 Instructions/Cycles 的比值，该值越大越好，阐明程序充分运用了处理器的特性。 Cache-references: cache 射中的次数 Cache-misses: cache 失效的次数。
经过指定 -e 选项，您能够改动 perf stat 的缺省作业 ( 关于作业，在上一末节现已阐明，能够经过 perf list 来检查 )。假定您现已有许多的调优经历，或许会运用 -e 选项来检查您所感兴趣的特其他作业。
3.3perf Top
Perf top 用于实时显现其时体系的功用核算信息。该指令首要用来调查整个体系其时的状况，比方能够经过检查该指令的输出来检查其时体系最耗时的内核函数或某个用户进程。
下面是 perf top 的或许输出：
PerfTop: 705 irqs/sec kernel:60.4% [1000Hz cycles] ————————————————– sampl pcnt function DSO 1503.00 49.2% t2 72.00 2.2% pthread_mutex_lock /lib/libpthread-2.12.so 68.00 2.1% delay_tsc [kernel.kallsyms] 55.00 1.7% aes_dec_blk [aes_i586] 55.00 1.7% drm_clflush_pages [drm] 52.00 1.6% system_call [kernel.kallsyms] 49.00 1.5% __memcpy_ssse3 /lib/libc-2.12.so 48.00 1.4% __strstr_ia32 /lib/libc-2.12.so 46.00 1.4% unix_poll [kernel.kallsyms] 42.00 1.3% __ieee754_pow /lib/libm-2.12.so 41.00 1.2% do_select [kernel.kallsyms] 40.00 1.2% pixman_rasterize_edges libpixman-1.so.0.18.0 37.00 1.1% _raw_spin_lock_irqsave [kernel.kallsyms] 36.00 1.1% _int_malloc /lib/libc-2.12.so ^C
很简略便发现 t2 是需求重视的可疑程序。不过其作案办法太简略：肆无忌惮地糟蹋着 CPU。所以咱们不必再做什么其他的作业便能够找到问题地点。但现实生活中，影响功用的程序一般都不会如此愚笨，所以咱们往往还需求运用其他的 perf 东西进一步剖析。
经过增加 -e 选项，您能够列出形成其他作业的 TopN 个进程 / 函数。比方 -e cache-miss，用来看看谁形成的 cache miss 最多。
3.4 运用 perf record, 解读 report
lenny@hbt:~/test$ perf record ./a.out [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.015 MB perf.data (~656 samples) ] lenny@hbt:~/test$ perf report Events: 12 cycles 62.29% a.out a.out [.] longa 35.17% a.out [kernel.kallsyms] [k] unmap_vmas 1.76% a.out [kernel.kallsyms] [k] __schedule 0.75% a.out [kernel.kallsyms] [k] ____cache_alloc 0.03% a.out [kernel.kallsyms] [k] native_write_msr_safe
perf record时加上-g选项，能够记载函数的调用联系，显现相似下面这样：
lenny@hbt:~/test$ perf record -g ./a.out [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.016 MB perf.data (~701 samples) ] lenny@hbt:~/test$ perf report Events: 14 cycles – 87.12% a.out a.out [.] longa – longa – 52.91% fun1 main __libc_start_main – 47.09% fun2 main __libc_start_main + 9.12% a.out [kernel.kallsyms] [k] vm_normal_page + 3.48% a.out [kernel.kallsyms] [k] _cond_resched + 0.28% a.out [kernel.kallsyms] [k] native_write_msr_safe
***运用 PMU 的比方下面这个比方 t3 参阅了文章“Branch and Loop Reorganization to Prevent Mispredicts”该比方调查程序对飞跃处理器分支猜测的运用率，如前所述，分支猜测能够明显进步处理器的功用，而分支猜测失利则明显下降处理器的功用。首要给出一个存在 BTB 失效的比方：
清单 3. 存在 BTB 失效的比方程序
//test.c #include #include void foo() { int i,j; for(i=0; i< 10; i++) j+=2; } int main(void) { int i; for(i = 0; i< 100000000; i++) foo(); return 0; }
用 gcc 编译生成测验程序 t3: gcc – o t3 – O0 test.c
用 perf stat 调查分支猜测的运用状况： [lm@ovispoly perf]$ ./perf stat ./t3
Performance counter stats for './t3': 6240.758394 task-clock-msecs # 0.995 CPUs 126 context-switches # 0.000 M/sec 12 CPU-migrations # 0.000 M/sec 80 page-faults # 0.000 M/sec 17683221 cycles # 2.834 M/sec (scaled from 99.78%) 10218147 instructions # 0.578 IPC (scaled from 99.83%) 2491317951 branches # 399.201 M/sec (scaled from 99.88%) 636140932 branch-misses # 25.534 % (scaled from 99.63%) 126383570 cache-references # 20.251 M/sec (scaled from 99.68%) 942937348 cache-misses # 151.093 M/sec (scaled from 99.58%) 6.271917679 seconds time elapsed
能够看到 branche-misses 的状况比较严重，25% 左右。我测验运用的机器的处理器为 Pentium4，其 BTB 的巨细为 16。而 test.c 中的循环迭代为 20 次，BTB 溢出，所以处理器的分支猜测将不精确。关于上面这句话我将扼要阐明一下，但关于 BTB 的细节，请阅览参阅文献 [6]。for 循环编译成为 IA 汇编后如下：
清单 4. 循环的汇编
// C code for ( i=0; i < 20; i++ ) { … } //Assembly code; mov esi, data mov ecx, 0 ForLoop: cmp ecx, 20 jge EndForLoop … add ecx, 1 jmp ForLoop EndForLoop:
能够看到，每次循环迭代中都有一个分支句子 jge，因此在运转进程中将有 20 次分支判别。每次分支判别都将写入 BTB，但 BTB 是一个 ring buffer，16 个 slot 写满后便开端掩盖。假定迭代次数正好为 16，或许小于 16，则完好的循环将悉数写入 BTB。
清单 5. 没有 BTB 失效的代码
#include #include void foo() { int i,j; for(i=0; i< 10; i++) j+=2; } int main(void) { int i; for(i = 0; i< 100000000; i++) foo(); return 0; }
此刻再次用 perf stat 采样得到如下成果： [lm@ovispoly perf]$ ./perf stat ./t3
Performance counter stats for './t3: 2784.004851 task-clock-msecs # 0.927 CPUs 90 context-switches # 0.000 M/sec 8 CPU-migrations # 0.000 M/sec 81 page-faults # 0.000 M/sec 33632545 cycles # 12.081 M/sec (scaled from 99.63%) 42996 instructions # 0.001 IPC (scaled from 99.71%) 1474321780 branches # 529.569 M/sec (scaled from 99.78%) 49733 branch-misses # 0.003 % (scaled from 99.35%) 7073107 cache-references # 2.541 M/sec (scaled from 99.42%) 47958540 cache-misses # 17.226 M/sec (scaled from 99.33%) 3.002673524 seconds time elapsed
Branch-misses 削减了。本例仅仅为了演示 perf 对 PMU 的运用，自身并无意义，关于充分运用 processor 进行调优能够参阅 Intel 公司出品的调优手册，其他的处理器或许有不同的办法，还期望读者明鉴。
3.5 运用 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 是有意义的，相似背单词之于学习英语相同，是一项缓慢苦楚却不得不做的作业。
3.6 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 点，想必您知道自己为什么要核算它吧？
3.7 Perf sched
调度器的好坏直接影响一个体系的全体运转功率。在这个范畴，内核黑客们常会发生争执，一个重要原因是关于不同的调度器，每个人给出的评测陈述都各不相同，乃至常常有相反的定论。因此一个威望的一致的评测东西将对完毕这种争辩有利。Perf sched 便是这种测验。
Perf sched 有五个子指令：
perf sched record # low-overhead recording of arbitrary workloads perf sched latency # output per task latency metrics perf sched map # show summary/map of context-switching perf sched trace # output finegrained trace perf sched replay # replay a captured workload using simlated threads
用户一般运用’ perf sched record ’搜集调度相关的数据，然后就能够用’ perf sched latency ’检查比方调度推迟等和调度器相关的核算数据。其他三个指令也相同读取 record 搜集到的数据并从其他不同的视点来展现这些数据。下面逐个进行演示。
perf sched record sleep 10 # record full system activity for 10 seconds perf sched latency –sort max # report latencies sorted by max ————————————————————————————- Task | Runtime ms | Switches | Average delay ms | Maximum delay ms | ————————————————————————————- :14086:14086 | 0.095 ms | 2 | avg: 3.445 ms | max: 6.891 ms | gnome-session:13792 | 31.713 ms | 102 | avg: 0.160 ms | max: 5.992 ms | metacity:14038 | 49.220 ms | 637 | avg: 0.066 ms | max: 5.942 ms | gconfd-2:13971 | 48.587 ms | 777 | avg: 0.047 ms | max: 5.793 ms | gnome-power-man:14050 | 140.601 ms | 434 | avg: 0.097 ms | max: 5.367 ms | python:14049 | 114.694 ms | 125 | avg: 0.120 ms | max: 5.343 ms | kblockd/1:236 | 3.458 ms | 498 | avg: 0.179 ms | max: 5.271 ms | Xorg:3122 | 1073.107 ms | 2920 | avg: 0.030 ms | max: 5.265 ms | dbus-daemon:2063 | 64.593 ms | 665 | avg: 0.103 ms | max: 4.730 ms | :14040:14040 | 30.786 ms | 255 | avg: 0.095 ms | max: 4.155 ms | events/1:8 | 0.105 ms | 13 | avg: 0.598 ms | max: 3.775 ms | console-kit-dae:2080 | 14.867 ms | 152 | avg: 0.142 ms | max: 3.760 ms | gnome-settings-:14023 | 572.653 ms | 979 | avg: 0.056 ms | max: 3.627 ms | … ———————————————————————————– TOTAL: | 3144.817 ms | 11654 | —————————————————
上面的比方展现了一个 Gnome 发动时的核算信息。
各个 column 的意义如下： Task: 进程的姓名和 pid Runtime: 实践运转时刻 Switches: 进程切换的次数 Average delay: 均匀的调度推迟 Maximum delay: 最大推迟
这儿最值得人们重视的是 Maximum delay，一般从这儿能够看到对交互性影响最大的特性：调度推迟，假定调度推迟比较大，那么用户就会感受到视频或许音频时断时续的。
其他的三个子指令供给了不同的视图，一般是由调度器的开发人员或许对调度器内部完结感兴趣的人们所运用。
首要是 map:
$ perf sched map …
N1 O1 . . . S1 . . . B0 . *I0 C1 . M1 . 23002.773423 secs N1 O1 . *Q0 . S1 . . . B0 . I0 C1 . M1 . 23002.773423 secs N1 O1 . Q0 . S1 . . . B0 . *R1 C1 . M1 . 23002.773485 secs N1 O1 . Q0 . S1 . *S0 . B0 . R1 C1 . M1 . 23002.773478 secs *L0 O1 . Q0 . S1 . S0 . B0 . R1 C1 . M1 . 23002.773523 secs L0 O1 . *. . S1 . S0 . B0 . R1 C1 . M1 . 23002.773531 secs L0 O1 . . . S1 . S0 . B0 . R1 C1 *T1 M1 . 23002.773547 secs T1 => irqbalance:2089 L0 O1 . . . S1 . S0 . *P0 . R1 C1 T1 M1 . 23002.773549 secs *N1 O1 . . . S1 . S0 . P0 . R1 C1 T1 M1 . 23002.773566 secs N1 O1 . . . *J0 . S0 . P0 . R1 C1 T1 M1 . 23002.773571 secs N1 O1 . . . J0 . S0 *B0 P0 . R1 C1 T1 M1 . 23002.773592 secs N1 O1 . . . J0 . *U0 B0 P0 . R1 C1 T1 M1 . 23002.773582 secs N1 O1 . . . *S1 . U0 B0 P0 . R1 C1 T1 M1 . 23002.773604 secs
星号表明调度作业发生地点的 CPU。
点号表明该 CPU 正在 IDLE。
Map 的优点在于供给了一个的总的视图，将成百上千的调度作业进行总结，显现了体系使命在 CPU 之间的散布，假定有欠好的调度搬迁，比方一个使命没有被及时搬迁到 idle 的 CPU 却被搬迁到其他繁忙的 CPU，相似这种调度器的问题能够从 map 的陈述中一眼看出来。假定说 map 供给了高度归纳的全体的陈述，那么 trace 就供给了最具体，最底层的细节陈述。
Perf replay 这个东西更是专门为调度器开发人员所规划，它企图重放 perf.data 文件中所记载的调度场景。许多状况下，一般用户假定发现调度器的古怪行为，他们也无法精确阐明发生该景象的场景，或许一些测验场景不简略再次重现，或许仅仅是出于“偷闲”的意图，运用 perf replay，perf 将模仿 perf.data 中的场景，无需开发人员花费许多的时刻去重现曩昔，这特别利于调试进程，由于需求一而再，再而三地重复新的修正是否能改进原始的调度场景所发现的问题。
下面是 replay 履行的示例： $ perf sched replay run measurement overhead: 3771 nsecs sleep measurement overhead: 66617 nsecs the run test took 999708 nsecs the sleep test took 1097207 nsecs nr_run_events: 200221 nr_sleep_events: 200235 nr_wakeup_events: 100130 task 0 ( perf: 13519), nr_events: 148 task 1 ( perf: 13520), nr_events: 200037 task 2 ( pipe-test-100k: 13521), nr_events: 300090 task 3 ( ksoftirqd/0: 4), nr_events: 8 task 4 ( swapper: 0), nr_events: 170 task 5 ( gnome-power-man: 3192), nr_events: 3 task 6 ( gdm-simple-gree: 3234), nr_events: 3 task 7 ( Xorg: 3122), nr_events: 5 task 8 ( hald-addon-stor: 2234), nr_events: 27 task 9 ( ata/0: 321), nr_events: 29 task 10 ( scsi_eh_4: 704), nr_events: 37 task 11 ( events/1: 8), nr_events: 3 task 12 ( events/0: 7), nr_events: 6 task 13 ( flush-8:0: 6980), nr_events: 20 ———————————————————— #1 : 2038.157, ravg: 2038.16, cpu: 0.09 / 0.09 #2 : 2042.153, ravg: 2038.56, cpu: 0.11 / 0.09 ^C
3.8 perf bench
除了调度器之外，许多时分人们都需求衡量自己的工刁难体系功用的影响。benchmark 是衡量功用的规范办法，关于同一个方针，假定能够有一个咱们都供认的 benchmark，将十分有助于”进步内核功用”这项作业。
现在，就我所知，perf bench 供给了 3 个 benchmark:
Sched message
sched message 是从经典的测验程序 hackbench 移植而来，用来衡量调度器的功用，overhead 以及可扩展性。该 benchmark 发动 N 个 reader/sender 进程或线程对，经过 IPC(socket 或许 pipe) 进行并发的读写。一般人们将 N 不断加大来衡量调度器的可扩展性。Sched message 的用法及用处和 hackbench 相同。
Sched Pipe
Sched pipe 从 Ingo Molnar 的 pipe-test-1m.c 移植而来。最初 Ingo 的原始程序是为了测验不同的调度器的功用和公平性的。其作业原理很简略，两个进程相互经过 pipe 拼命地发 1000000 个整数，进程 A 发给 B，一起 B 发给 A。。。由于 A 和 B 相互依靠，因此假定调度器不公平，对 A 比 B 好，那么 A 和 B 全体所需求的时刻就会更长。
Mem memcpy
这个是 perf bench 的作者 Hitoshi Mitake 自己写的一个履行 memcpy 的 benchmark。该测验衡量一个复制 1M 数据的 memcpy() 函数所花费的时刻。我尚不理解该 benchmark 的运用场景。。。或许是一个比方，告知人们怎么运用 perf bench 结构开发更多的 benchmark 吧。
这三个 benchmark 给咱们展现了一个或许的未来：不同言语，不同肤色，来自不同布景的人们将来会选用相同的 benchmark，只需有一份 Linux 内核代码即可。
3.9 perf lock
锁是内核同步的办法，一旦加了锁，其他预备加锁的内核履行途径就有必要等候，下降了并行。因此关于锁进行专门剖析应该是调优的一项重要作业。
3.10 perf Kmem
Perf Kmem 专门搜集内核 slab 分配器的相关作业。比方内存分配，开释等。能够用来研讨程序在哪里分配了许多内存，或许在什么当地发生碎片之类的和内存办理相关的问题。
Perf kmem 和 perf lock 实践上都是 perf tracepoint 的特例，您也彻底能够用 Perf record – e kmem: 或许 perf record – e lock: 来完结相同的功用。但重要的是，这些东西在内部对原始数据进行了汇总和剖析，因此能够发生信息愈加清晰愈加有用的核算报表。
3.11 Perf timechart
许多 perf 指令都是为调试单个程序或许单个意图而规划。有些时分，功用问题并非由单个原因所引起，需求从各个视点逐个检查。为此，人们常需求综合运用各种东西，比方 top,vmstat,oprofile 或许 perf。这十分费事。
此外，前面介绍的一切东西都是根据指令行的，陈述不行直观。更令人泄气的是，一些陈述中的参数令人费解。所以人们更乐意具有一个“傻瓜式”的东西。
以上种种便是 perf timechart 的愿望，其创意来源于 bootchart。选用“简略”的图形“一望而知”地提醒问题地点。
Timechart 能够显现更具体的信息，实践上是一个矢量图形 SVG 格局，用 SVG viewer 的扩大功用，咱们能够将该图的细节部分扩大，timechart 的规划理念叫做”infinitely zoomable”。扩大之后便能够看到一些更具体的信息，相似网上的 google 地图，找到国家之后，能够扩大，看城市的散布，再扩大，能够看到某个城市的大街散布，还能够扩大以便得到愈加具体的信息。完好的 timechart 图形和色彩解读超出了本文的规模，感兴趣的读者能够到作者 Arjan 的博客上检查。
