性能瓶颈找不到？ftrace+perf组合拳，5分钟定位内核问题

嵌入式Linux最让人头秃的场景：系统卡了，但你不知道卡在哪。

CPU跑满了吗？谁在吃CPU？是内核态还是用户态？中断太多了还是调度出问题了？还是DMA卡住了？

不用猜，ftrace和perf这两个Linux自带的工具，连安装都不用，能回答你所有问题。

先说perf——谁在吃CPU

perf是基于硬件性能计数器的采样工具，开销极低，适合"不知道问题在哪"的盲搜阶段。

1. 看CPU使用率

# 看CPU在忙什么perftop

按比例显示各函数占用的CPU。看到irq_work排第一？那八成是中断风暴。看到do_sys_open排第一？有人在疯狂打开关闭文件。

2. 热点函数定位

# 采样10秒，存数据perf record-g-a--sleep10# 分析热点perf report

-g记录调用链，-a所有CPU。看完就知道最热的函数是谁调起来的。

3. 上下文切换分析

怀疑系统在频繁切换进程？

perf sched record --sleep5perf 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

cd/sys/kernel/tracing# 设置要trace的函数echo__alloc_pages_nodemask>set_graph_functionechofunction_graph>current_tracerecho1>tracing_onsleep3echo0>tracing_on# 看结果cattrace|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. 中断/调度跟踪

echo0>tracing_onecho>trace# 清空缓冲区echoirq:irq_handler_entry>set_eventechosched:sched_switch>set_eventecho1>tracing_onsleep3echo0>tracing_oncattrace

可以看到每个中断的发生频率、处理时间，以及每次调度切换的原进程→目标进程。

3. 动态事件（最狠的）

不想trace内核函数？想trace你自己的驱动？不用改代码：

echo'p:myprobe my_driver_write arg1=$arg1 arg2=$arg2'>kprobe_eventsecho1>events/kprobes/myprobe/enable

甚至可以在函数返回时看返回值：

echo'r:myret my_driver_read $retval'>kprobe_events

不用重新编译内核，不用加printk，不用重新部署驱动。这就是ftrace最狠的地方。

perf + ftrace 组合拳实战

光讲单个工具没意思，来一个真实场景：CPU idle时功耗居高不下。

第一步：perf top扫一下

Events: 1K cycles 43.21% [kernel] [k] __do_softirq

好，软中断太频繁。

第二步：perf record看谁发的中断

perf record-eirq:irq_handler_entry-a--sleep5perf script

看到/proc/interrupts里eth0的TX中断每秒触发了2000次。但这设备明明没多少数据在发。

第三步：ftrace看中断处理过程

echofunction_graph>current_tracerechoeth_irq_handler>set_graph_functionecho1>tracing_on;sleep2;echo0>tracing_oncattrace

发现中断处理函数里调了一个wake_up_process，唤醒了一个worker线程，但那worker大部分时间无事可做，又schedule回去了——白忙一场。

第四步：解决方案

原来网卡驱动在NAPI poll模式下，每次中断都调用了napi_schedule。但没判断实际是否有数据。加上空包检测后，中断次数从2000次/秒降到300次/秒，CPU idle时的功耗直接降了0.5W。

这个案例里，没有perf和ftrace，你只能在代码里一行行看、加printk重编、部署、复现——一个下午就没了。用工具，10分钟。

速查表

一句话总结

perf告诉你"哪慢"，ftrace告诉你"为什么慢"。两个加起来，嵌入式Linux性能问题99%都能在10分钟内定位。别再只会top+printk了，那是上一个十年的玩法。