性能瓶颈找不到？ftrace+perf组合拳，5分钟定位内核问题
嵌入式Linux最让人头秃的场景：系统卡了，但你不知道卡在哪。
CPU跑满了吗？谁在吃CPU？是内核态还是用户态？中断太多了还是调度出问题了？还是DMA卡住了？
不用猜，ftrace和perf这两个Linux自带的工具，连安装都不用，能回答你所有问题。
先说perf------谁在吃CPU
perf是基于硬件性能计数器的采样工具，开销极低，适合"不知道问题在哪"的盲搜阶段。
1. 看CPU使用率
bash
# 看CPU在忙什么
perf top按比例显示各函数占用的CPU。看到 irq_work 排第一？那八成是中断风暴。看到 do_sys_open 排第一？有人在疯狂打开关闭文件。
2. 热点函数定位
bash
# 采样10秒，存数据
perf record -g -a --sleep 10
# 分析热点
perf report-g 记录调用链，-a 所有CPU。看完就知道最热的函数是谁调起来的。
3. 上下文切换分析
怀疑系统在频繁切换进程？
bash
perf sched record -- sleep 5
perf sched latency输出每个进程的调度延迟。看到某个进程平均延迟几十ms？那它可能被优先级更高的中断或实时线程饿死了。
真实案例 ：一次监控摄像头画面卡顿。perf top一看，copy_page 占CPU 40%------哪个缺德的在大量拷贝内存？perf report看调用链，定位到v4l2的vb2 buffer queue里，有个不合理的memcpy。加上dma_buf直接映射后，CPU直接降到5%。
再说ftrace------内核内部的"printk"但不用重编
ftrace是内核自带的trace框架，几乎不耗资源就可以trace内核函数的调用。新版内核用 tracefs 挂在 /sys/kernel/tracing（老的在debugfs）。
1. 打开function graph
bash
cd /sys/kernel/tracing
# 设置要trace的函数
echo __alloc_pages_nodemask > set_graph_function
echo function_graph > current_tracer
echo 1 > tracing_on
sleep 3
echo 0 > tracing_on
# 看结果
cat trace | head -50输出类似：
kworker/1:0-98 [001] ... 1234.5678: __alloc_pages_nodemask() {
kworker/1:0-98 [001] ... 1234.5679: get_page_from_freelist() {
kworker/1:0-98 [001] ... 1234.5680: zone_watermark_ok() {
kworker/1:0-98 [001] ... 1234.5680: }
...
kworker/1:0-98 [001] ... 1234.5695: }
kworker/1:0-98 [001] ... 1234.5696: }每一层缩进代表函数调用深度，秒级看出谁慢。
2. 中断/调度跟踪
bash
echo 0 > tracing_on
echo > trace # 清空缓冲区
echo irq:irq_handler_entry > set_event
echo sched:sched_switch > set_event
echo 1 > tracing_on
sleep 3
echo 0 > tracing_on
cat trace可以看到每个中断的发生频率、处理时间，以及每次调度切换的原进程→目标进程。
3. 动态事件（最狠的）
不想trace内核函数？想trace你自己的驱动？不用改代码：
bash
echo 'p:myprobe my_driver_write arg1=$arg1 arg2=$arg2' > kprobe_events
echo 1 > events/kprobes/myprobe/enable甚至可以在函数返回时看返回值：
bash
echo 'r:myret my_driver_read $retval' > kprobe_events不用重新编译内核，不用加printk，不用重新部署驱动。 这就是ftrace最狠的地方。
#mermaid-svg-FMjRTVIfcM9IRydk{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-FMjRTVIfcM9IRydk .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-FMjRTVIfcM9IRydk .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-FMjRTVIfcM9IRydk .error-icon{fill:#552222;}#mermaid-svg-FMjRTVIfcM9IRydk .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-FMjRTVIfcM9IRydk .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-FMjRTVIfcM9IRydk .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-FMjRTVIfcM9IRydk .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-FMjRTVIfcM9IRydk .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-FMjRTVIfcM9IRydk .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-FMjRTVIfcM9IRydk .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-FMjRTVIfcM9IRydk .marker{fill:#333333;stroke:#333333;}#mermaid-svg-FMjRTVIfcM9IRydk .marker.cross{stroke:#333333;}#mermaid-svg-FMjRTVIfcM9IRydk svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-FMjRTVIfcM9IRydk p{margin:0;}#mermaid-svg-FMjRTVIfcM9IRydk .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-FMjRTVIfcM9IRydk .cluster-label text{fill:#333;}#mermaid-svg-FMjRTVIfcM9IRydk .cluster-label span{color:#333;}#mermaid-svg-FMjRTVIfcM9IRydk .cluster-label span p{background-color:transparent;}#mermaid-svg-FMjRTVIfcM9IRydk .label text,#mermaid-svg-FMjRTVIfcM9IRydk span{fill:#333;color:#333;}#mermaid-svg-FMjRTVIfcM9IRydk .node rect,#mermaid-svg-FMjRTVIfcM9IRydk .node circle,#mermaid-svg-FMjRTVIfcM9IRydk .node ellipse,#mermaid-svg-FMjRTVIfcM9IRydk .node polygon,#mermaid-svg-FMjRTVIfcM9IRydk .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-FMjRTVIfcM9IRydk .rough-node .label text,#mermaid-svg-FMjRTVIfcM9IRydk .node .label text,#mermaid-svg-FMjRTVIfcM9IRydk .image-shape .label,#mermaid-svg-FMjRTVIfcM9IRydk .icon-shape .label{text-anchor:middle;}#mermaid-svg-FMjRTVIfcM9IRydk .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-FMjRTVIfcM9IRydk .rough-node .label,#mermaid-svg-FMjRTVIfcM9IRydk .node .label,#mermaid-svg-FMjRTVIfcM9IRydk .image-shape .label,#mermaid-svg-FMjRTVIfcM9IRydk .icon-shape .label{text-align:center;}#mermaid-svg-FMjRTVIfcM9IRydk .node.clickable{cursor:pointer;}#mermaid-svg-FMjRTVIfcM9IRydk .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-FMjRTVIfcM9IRydk .arrowheadPath{fill:#333333;}#mermaid-svg-FMjRTVIfcM9IRydk .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-FMjRTVIfcM9IRydk .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-FMjRTVIfcM9IRydk .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-FMjRTVIfcM9IRydk .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-FMjRTVIfcM9IRydk .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-FMjRTVIfcM9IRydk .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-FMjRTVIfcM9IRydk .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-FMjRTVIfcM9IRydk .cluster text{fill:#333;}#mermaid-svg-FMjRTVIfcM9IRydk .cluster span{color:#333;}#mermaid-svg-FMjRTVIfcM9IRydk div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-FMjRTVIfcM9IRydk .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-FMjRTVIfcM9IRydk rect.text{fill:none;stroke-width:0;}#mermaid-svg-FMjRTVIfcM9IRydk .icon-shape,#mermaid-svg-FMjRTVIfcM9IRydk .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-FMjRTVIfcM9IRydk .icon-shape p,#mermaid-svg-FMjRTVIfcM9IRydk .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-FMjRTVIfcM9IRydk .icon-shape .label rect,#mermaid-svg-FMjRTVIfcM9IRydk .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-FMjRTVIfcM9IRydk .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-FMjRTVIfcM9IRydk .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-FMjRTVIfcM9IRydk :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} CPU繁忙
调度延迟
IO等待
内核函数
中断/调度
自定义驱动
系统卡顿
perf top 初步扫描
perf record/report 定位热点函数
perf sched latency
iostat + perf
需要更细的trace?
ftrace function_graph
ftrace event trace
kprobe 动态插桩
找到瓶颈
perf + ftrace 组合拳实战
光讲单个工具没意思，来一个真实场景：CPU idle时功耗居高不下。
第一步：perf top扫一下
Events: 1K cycles
43.21% [kernel] [k] __do_softirq好，软中断太频繁。
第二步：perf record看谁发的中断
bash
perf record -e irq:irq_handler_entry -a --sleep 5
perf script看到 /proc/interrupts 里eth0的TX中断每秒触发了2000次。但这设备明明没多少数据在发。
第三步：ftrace看中断处理过程
bash
echo function_graph > current_tracer
echo eth_irq_handler > set_graph_function
echo 1 > tracing_on; sleep 2; echo 0 > tracing_on
cat trace发现中断处理函数里调了一个 wake_up_process，唤醒了一个worker线程，但那worker大部分时间无事可做，又schedule回去了------白忙一场。
第四步：解决方案
原来网卡驱动在 NAPI poll 模式下，每次中断都调用了 napi_schedule。但没判断实际是否有数据。加上空包检测后，中断次数从2000次/秒降到300次/秒，CPU idle时的功耗直接降了0.5W。
这个案例里，没有perf和ftrace，你只能在代码里一行行看、加printk重编、部署、复现------一个下午就没了。用工具，10分钟。
速查表
| 场景 | 工具 | 命令 |
|---|---|---|
| 谁在吃CPU | perf top | perf top |
| 热点函数调用链 | perf record/report | perf record -g -a sleep 10 |
| 调度延迟 | perf sched | perf sched latency |
| Cache Miss | perf stat | perf stat -e cache-misses ./app |
| 内核函数调用图 | ftrace | echo function_graph > current_tracer |
| 中断频率 | ftrace event | echo irq:irq_handler_entry > set_event |
| 函数参数/返回值 | kprobe | echo 'p:...' > kprobe_events |
| 谁调了特定函数 | ftrace filter | echo func > set_ftrace_filter |
一句话总结
perf告诉你"哪慢"，ftrace告诉你"为什么慢"。 两个加起来，嵌入式Linux性能问题99%都能在10分钟内定位。别再只会 top + printk 了，那是上一个十年的玩法。