性能调优工具如 perf，Oprofile 等的基本原理都是对被监测对象进行采样，最简单的情形是根据 tick 中断进行采样，即在 tick 中断内触发采样点，在采样点里判断程序当时的上下文。
事件分为以下三种：
1）Hardware Event 是由 PMU 硬件产生的事件，比如 cache 命中，当您需要了解程序对硬件特性的使用情况时，便需要对这些事件进行采样；
2）Software Event 是内核软件产生的事件，比如进程切换，tick 数等 ;
3）Tracepoint event 是内核中的静态 tracepoint 所触发的事件，这些 tracepoint 用来判断程序运行期间内核的行为细节，比如 slab 分配器的分配次数等。
Perf是内置于Linux内核源码树中的性能剖析(profiling)工具。
它基于事件采样原理，以性能事件为基础，支持针对处理器相关性能指标与操作系统相关性能指标的性能剖析。常用于性能瓶颈的查找与热点代码的定位。
CPU周期(cpu-cycles)是默认的性能事件，所谓的CPU周期是指CPU所能识别的最小时间单元，通常为亿分之几秒，是CPU执行最简单的指令时所需要的时间，例如读取寄存器中的内容，也叫做clock tick。
Perf是一个包含22种子工具的工具集，以下是最常用的5种.
perf list
Perf ist用来查看perf所支持的性能事件，有软件的也有硬件的。
List all symbolic event types.
perf list [hw | sw | cache | tracepoint | event_glob]
性能事件的分布
hw：Hardware event，9个
sw：Software event，9个
cache：Hardware cache event，26个
tracepoint：Tracepoint event，775个
sw实际上是内核的计数器，与硬件无关。
hw和cache是CPU架构相关的，依赖于具体硬件。
tracepoint是基于内核的ftrace，主线2.6.3x以上的内核版本才支持。
指定性能事件(以它的属性)
-e : u // userspace
-e : k // kernel
-e : h // hypervisor
-e : G // guest counting (in KVM guests)
-e : H // host counting (not in KVM guests)
(3) 使用例子
显示内核和模块中，消耗最多CPU周期的函数：
# perf top -e cycles:k
显示分配高速缓存最多的函数：
# perf top -e kmem:kmem_cache_alloc
perf top
对于一个指定的性能事件(默认是CPU周期)，显示消耗最多的函数或指令。
System profiling tool.
Generates and displays a performance counter profile in real time.
perf top [-e | --event=EVENT] []
perf top主要用于实时分析各个函数在某个性能事件上的热度，能够快速的定位热点函数，包括应用程序函数、
模块函数与内核函数，甚至能够定位到热点指令。默认的性能事件为cpu cycles。
perf stat
用于分析指定程序的性能概况。
Run a command and gather performance counter statistics.
perf stat [-e | --event=EVENT] [-a]
perf stat [-e | --event=EVENT] [-a] - []
输出格式
# perf stat ls
输出包括ls的执行时间，以及10个性能事件的统计。
task-clock：任务真正占用的处理器时间，单位为ms。CPUs utilized = task-clock / time elapsed，CPU的占用率。
context-switches：上下文的切换次数。
CPU-migrations：处理器迁移次数。Linux为了维持多个处理器的负载均衡，在特定条件下会将某个任务从一个CPU
迁移到另一个CPU。
page-faults：缺页异常的次数。当应用程序请求的页面尚未建立、请求的页面不在内存中，或者请求的页面虽然在内
存中，但物理地址和虚拟地址的映射关系尚未建立时，都会触发一次缺页异常。另外TLB不命中，页面访问权限不匹配
等情况也会触发缺页异常。
cycles：消耗的处理器周期数。如果把被ls使用的cpu cycles看成是一个处理器的
可以用cycles / task-clock算出。
stalled-cycles-frontend：略过。
stalled-cycles-backend：略过。
instructions：执行了多少条指令。IPC为平均每个cpu cycle执行了多少条指令。
branches：遇到的分支指令数。branch-misses是预测错误的分支指令数。
常用参数
-p：stat events on existing process id (comma separated list). 仅分析目标进程及其创建的线程。
-a：system-wide collection from all CPUs. 从所有CPU上收集性能数据。
-r：repeat command and print average + stddev (max: 100). 重复执行命令求平均。
-C：Count only on the list of CPUs provided (comma separated list), 从指定CPU上收集性能数据。
-v：be more verbose (show counter open errors, etc), 显示更多性能数据。
-n：null run - don't start any counters，只显示任务的执行时间 。
-x SEP：指定输出列的分隔符。
-o file：指定输出文件，--append指定追加模式。
--pre ：执行目标程序前先执行的程序。
--post ：执行目标程序后再执行的程序。
使用例子
执行10次程序，给出标准偏差与期望的比值：
# perf stat -r 10 ls > /dev/null
显示更详细的信息：
# perf stat -v ls > /dev/null
只显示任务执行时间，不显示性能计数器：
# perf stat -n ls > /dev/null
单独给出每个CPU上的信息：
# perf stat -a -A ls > /dev/null
ls命令执行了多少次系统调用：
# perf stat -e syscalls:sys_enter ls
perf record
收集采样信息，并将其记录在数据文件中。
随后可以通过其它工具(perf-report)对数据文件进行分析，结果类似于perf-top的。
常用参数
-e：Select the PMU event.
-a：System-wide collection from all CPUs.
-p：Record events on existing process ID (comma separated list).
-A：Append to the output file to do incremental profiling.
-f：Overwrite existing data file.
-o：Output file name.
-g：Do call-graph (stack chain/backtrace) recording.
-C：Collect samples only on the list of CPUs provided.
使用例子
记录nginx进程的性能数据：
# perf record -p `pgrep -d ',' nginx`
记录执行ls时的性能数据：
# perf record ls -g
记录执行ls时的系统调用，可以知道哪些系统调用最频繁：
# perf record -e syscalls:sys_enter ls
perf report
读取perf record创建的数据文件，并给出热点分析结果。
除了以上5个常用工具外，还有一些适用于较特殊场景的工具， 比如内核锁、slab分配器、调度器，
也支持自定义探测点。
perf lock
内核锁的性能分析。
Analyze lock events.
perf lock {record | report | script | info}
需要编译选项的支持：CONFIG_LOCKDEP、CONFIG_LOCK_STAT。
CONFIG_LOCKDEP defines acquired and release events.
CONFIG_LOCK_STAT defines contended and acquired lock events.
常用选项
-i ：输入文件
-k ：sorting key，默认为acquired，还可以按contended、wait_total、wait_max和wait_min来排序。
使用例子
# perf lock record ls // 记录
# perf lock report // 报告
Name：内核锁的名字。
aquired：该锁被直接获得的次数，因为没有其它内核路径占用该锁，此时不用等待。
contended：该锁等待后获得的次数，此时被其它内核路径占用，需要等待。
total wait：为了获得该锁，总共的等待时间。
max wait：为了获得该锁，最大的等待时间。
min wait：为了获得该锁，最小的等待时间。
perf kmem
slab分配器的性能分析。
Tool to trace/measure kernel memory(slab) properties.
perf kmem {record | stat} []
常用选项
--i ：输入文件
--caller：show per-callsite statistics，显示内核中调用kmalloc和kfree的地方。
--alloc：show per-allocation statistics，显示分配的内存地址。
-l ：print n lines only，只显示num行。
-s ：sort the output (default: frag,hit,bytes)
使用例子
# perf kmem record ls // 记录
# perf kmem stat --caller --alloc -l 20 // 报告
Callsite：内核代码中调用kmalloc和kfree的地方。
Total_alloc/Per：总共分配的内存大小，平均每次分配的内存大小。
Total_req/Per：总共请求的内存大小，平均每次请求的内存大小。
Hit：调用的次数。
Ping-pong：kmalloc和kfree不被同一个CPU执行时的次数，这会导致cache效率降低。
Frag：碎片所占的百分比，碎片 = 分配的内存 - 请求的内存，这部分是浪费的。
有使用--alloc选项，还会看到Alloc Ptr，即所分配内存的地址。
TASK：进程名和pid。
Runtime：实际的运行时间。
Switches：进程切换的次数。
Average delay：平均的调度延迟。
Maximum delay：最大的调度延迟。
Maximum delay at：最大调度延迟发生的时刻。
probe-sched
调度模块分析。
trace/measure scheduler properties (latencies)
perf sched {record | latency | map | replay | script}
使用例子
# perf sched record sleep 10 // perf sched record
# perf report latency --sort max
perf-probe
自定义探测点。
Define new dynamic tracepoints.
使用例子
Display which lines in schedule() can be probed
# perf probe --line schedule
前面有行号的可以探测，没有行号的就不行了。
(2) Add a probe on schedule() function 12th line.
# perf probe -a schedule:12
在schedule函数的12处增加一个探测点。
程序一
void longa()
{
int i,j;
for(i = 0; i < 1000000; i++)
j=i; //am I silly or crazy? I feel boring and desperate.
}
void foo2()
{
int i;
for(i=0 ; i < 10; i++)
longa();
}
void foo1()
{
int i;
for(i = 0; i< 100; i++)
longa();
}
int main(void)
{
foo1();
foo2();
}
编译如下：gcc -o test1 -g test.c
此处一定要加-g选项，加入调试和符号表信息。
执行如下：
perf stat ./test
Performance counter stats for './test':
256.955398task-clock (msec)#0.999 CPUs utilized
4context-switches#0.016 K/sec
0cpu-migrations#0.000 K/sec
44page-faults#0.171 K/sec
cycles
stalled-cycles-frontend
stalled-cycles-backend
instructions
branches
branch-misses
0.257177573 seconds time elapsed
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 失效的次数。
查找时间上的热点函数
perf record -e cpu-clock ./test1
perf report
显示如下：
Samples: 188of event 'cpu-clock', Event count (approx.): 47000000
OverheadCommandShared ObjectSymbol
99.47%testtest[.] longa
0.53%test[kernel.kallsyms][k] finish_task_switch
