ftrace介绍

static ftrace

gcc -pg选项，将每个函数都将先调用__mcount，所有函数都共用同一个stub函数

dynamic ftrace

在函数前插入nop（什么都不做的指令）指令

在开启某一个函数trace时，将函数前面的nop指令改为跳转到stub函数的指令

ftrace_run_update_code()更改nop指令时，芯片层面实现同步机制（暂停其他核）避免由于并发导致问题，等待nop指令更新完成

初探ftrace

开启Ftrace前后变化

获取代码段

以vio_fps_calculate为例：

得到虚拟地址后，编写一个模块去读取对应的代码段

转指令码

此时得到的是二进制的代码段，使用python 将其整理为指令码

指令码转目标文件

反汇编目标文件

对比代码段前后变化

可以发现改变了两个指令

开启trace 后，将预埋的nop之指令改为跳转指令，跳转执行trace_evnet。

Linux源码

ftrace抓函数调用耗时

在同时打开Enable CONFIG_FUNCTION_TRACER和CONFIG_FUNCTION_GRAPH_TRACER。编译器会在每一个函数的入口插入一个ftrace_caller的函数

开启ftrace graph前后代码段的变化

trace-cmd start -l ion_import_dma_buf_with_shareid -p function_graph

nop指令替换为bl指令，跳转的地址 ffff800008970780 + 0xffffffffff6bddcc = ffff80000802e54c（ftrace_caller）

ftrace使用实战

Trace-cmd

修改缓冲区大小

查看可跟踪的事件和函数

跟踪特定PID

跟踪特定函数

trace_printk

对时序影响很小的打印函数，适合于定位加日志不复现的问题

VPS 定制化 trace 工具

增加了一些event

hobot-drivers/camsys/vpf/vio_trace.h

使用方法

帧率统计

每个模块处理完成后会产生一个frame_done中断，此时会记录下一个event点，此时在时间轴上每一帧则对应一个个离散的点。按照时间进行resample(重采样)，得到每秒的帧率数据序列，此种方法可以较为直观的反应帧率变化。

暂时无法在飞书文档外展示此内容

延迟统计

对于延迟会统计两个数据，第一个是硬件处理引入的耗时，这个数据一般与处理尺寸相关相对固定，这个耗时称为模块延迟（module latency）；另外一个是从cim 接受到一行数据产生frame_start开始到当前模块frame_end的耗时，这个耗时包括sensor的出图完成+前级IP硬件处理耗时+软件耗时，这个延迟称为到某模块的通路延迟（flow latency）。

模块延迟

只需要将该模块trace的帧event中的fe时间戳 - fs时间戳即可得到硬件处理耗时，即为module latency

通路延迟

在trace的event中会传递cim的fs时间戳（timestamp），因此只需将模块的fe event时间戳-timestamp，即可得到从第一行像素输入开始到当前的整个通路延迟。

如以到GDC的通路延迟为例，那么统计的通路延迟就包含如图所示的所有延迟。