常用perf指令
perf event是内核的一部分，在tools/perf下面。
cmd:
perf record -e [probe] -ag
-a trace所有cpu
-g 追踪stack调用栈data--写入-->perf.data文件
ctrl-c 停止追踪
perf report 显示分析报告
开销排序：
小| 统计/count 统计事件数量
| 采样
大| trace 收集事件细节
V
具体的使用方式可以查man
分类列出perf指令
列出：
perf list 列出所有event
perf list 'sched:* ' 列出某一类tracepoint
计数器：
perf stat 加各种参数
perf stat command （针对特定的指令或者PID）
-d 显示细节 details
-p PID
-a 记录所有东西‘
sleep 5 记录5秒
刨析/采样
perf record 同样加cmd或者-p PID 来监测特定的内容
-F 采样频率 单位Hz
-g 抓call stack
--call-graph dwarf 使用dwarf符号记录栈
关于"--"看起来似乎是加在带参数的command 之前的。
动态加探针
perf probe 指令
在 perf probe 的使用中，很多地方需要使用debug info。这是否意味着需要gcc -g?
[--add] tcp_sendmsg 在内核函数入口加tracepoint
-d/--del删除tp
-V 显示可用变量
perf probe似乎是在'probe:*'下增加了一个tracepoint. 可用再通过perf record使能和记录。
显示报告
perf report 报告形式输出
perf script 列出所有event记录（记录表 细节条目）
ftrace和perf
ftrace 是基于debugfs的一套前端
底层数据源也是tracepoint kprobe uprobe
常见套路：
perf-->采样刨析
|
v
热点函数-->ftrace定量分析-->调用过程
前端工具：
debugfs
trace-cmd---------->对debugfs的操作的封装
perf-tools
可用追踪进程 函数 子函数
+++++++++++++++++++++++++
perf 采样 不能坐函数遍历
children |
self |
统计自己和子函数的比分比 |
只统计落在自己内的 子函数外的百分比 |
perf安装
使用perf可能会提示安装，按照提示安装即可，也可以从内核源码编译安装
所需要的symbols可能需要安装一些包或者开启内核配置选项来支持
关于symbols
->符号 帮助我们从地址映射到函数或者变量名，人们才能理解
-> 使用perf可能会提示安装包含symbols的debug包，多以'--dbgsym'结尾
->你可以检查编译系统配置以保留符号信息
->对于内核级别的符号，可以安装内核的debuginfo包或者使能CONFIG_KALLSYMS
Stack Traces
编译时不要省略frame pointers !!!
对GCC来讲 可用编译参数：
-fno-omit-frame-pointer
对内核来讲是：
CONFIG_FRAME_POINTER=y
没有FP 记录不了 代码回溯。可用用dwarf或者LBR来顶一顶，但是也不见得好用。
使能tracepoint
perf record -e 'sched:sched_process_*' -a sleep 5Tracepoint不是使用采样/刨析来捕获？不受频率影响？
按频率采样CPU获得调用栈
perf record -F Hz原理是创造周期中断事件 来让perf捕获 同时记录指针
事件源
software event
由perf提供 数量较少
softevent有default period 采样的时候是采集到一定的数量报一次（不然报太多了 你看stack有一个给你看就够了）可以通过perf record -vv看具体的。
PMC
硬件性能计数器 和处理器相关
实际上一般会复用寄存器 来记录不同的事件发生的次数。实现不同的功能。要配置。
应用场景：cpu cycles; cache miss之类
Kernel Trace point
内核中的代码埋点，可用于你的自己的trace工具开发，较稳定。
经由设计人员仔细考究，很常用。
USDT
用户层代码的静态埋点
需要先在环境中安装USDT的库，以dtrace为代表。【API 也比较稳定】
例如：apt install systemtap-sdt-dev
安装 dtrace
然后将已埋好USDT的API的代码与库一起编译
例如：./configure --with-dtrace
make -j64
Dtrace是USDT的代表，LTTng也有USDT
Dynamic Tracing
不稳定 因为是之间抓代码
通过 perf probe --add之间加tracepoint
可以在内核和程序运行时动态增加，在probe处运行一些新加的指令。
使用之前无开销，用完删了probe之后也无开销。
stat 统计 （PMC）
perf stat CMD 分析PMCs
常用指标“insns per cycles”即所谓的IPC。每周期指令数。
IPC高--->CPU吞吐高--->很好
IPC低--->stall多
需要注意有没有spin lock CPU 空转不干活。
可以通过perf stat -d 进一步看细节
比较有用的指标是：“stalled cycles per insns”
代表了mem和资源总线访问 代表了延时。越低越好。
剖析
Timed Profiling
按照一定的时间间隔采样 instruction pointer和stack trace
例： perf record -F 99 -a -g --sleep 30
【采样 99 赫兹而不是100赫兹是为了防止与某些周期任务冲突导致偏移】
Event Profiling
以硬件时间作为采样触发 而不是时钟
硬件事件可能在短时间内发生太多，每次都出发记录可能导致太大的开销。
所以一般用-C count的方式设置触发阈值。
在每次捕获这么多的事件后才记录一次stack。
例如： perf record -e Lrdxaxhe-load-misses -c 10000 -ag -- sleep 5
注意：
很多CPU会在触发采样后故意引入很小的延时以避免锁步
这对time profiling几乎没有影响 但是对于事件采样 会造成采样不准。
解决方法：所谓的“precise sampling”
不一定所有的PMC都支持精确采样，可以通过“perf record -vv”查看“precise_ip”的值来确认。
启用方法 在PMC事件后加“:p”
例如：“-e instructions:p”
static kernel tracing
tracepoint和其他静态事件也可以使用counter计数
例如：perf stat -e "syscalls:sys_enter_*"
对比perf和strace
strace的底层是使用ptrace 原理是类似GDB。会在目标位置断点代码执行，strace执行开销巨大
dynamic tracing
内核选项：
CONFIG_KPROBES=y
CONFIG_KPROBE_EVENTS=y
CONFIG_FRAME_POINTER=y
CONFIG_UPROBES=y
CONFIG_UPROBE_EVENTS=y
如果开启了debuginfo
CONFIG_DEBUG_INFO=y
可以记录函数中的内核变量
显示出每条记录中当前变量的大小
例如：
perf probe -V tcp_sendmsg 列出所有可用变量
perf probe --add 'tcp_sendmsg size' 加probe同时记录size
perf record -e probe:tcp_sendmsg -a 使能并开始记录
在有debuginfo的情况下，也可以根据内核函数的行号 来加trace point
例：
perf probe -L tcp_sendmsg 列出可用 的 line probe
perf probe -V tcp_send:81 列出第81行可见变量
perf probe --add 'tcp_sendmsg:81 seglen' 加 probe
perf record -e probe:tcp_sendmsg -a 开始记录