ftrace

最新推荐文章于 2024-08-07 16:27:35 发布

破木吉他

最新推荐文章于 2024-08-07 16:27:35 发布

阅读量3.8k

点赞数 2

分类专栏： Linux 理解linux内核框架文章标签： ftrace

本文链接：https://blog.csdn.net/je930502/article/details/80412771

版权

Linux 同时被 2 个专栏收录

9 篇文章 0 订阅

订阅专栏

理解linux内核框架

7 篇文章 2 订阅

订阅专栏

一直就知道有这么个工具ftrace，没使用过，恰好这段时间有个bug，想着用这个工具追踪了一下。叫ftrace总给我的感觉是个用户态工具，ftrace –help 用法就一览无余了。其实并非如此，ftrace结合debugfs挂载使用，需要手动操作一些文件系统接口实现trace的目的。如开启或关闭调试，分别向tracing_on文件写0或1，详见实例。为什么没有提供一个更方便的工具？经过这些天的试用，简单来说说，1/ 提供一种trace机制，linux有机制和策略一说，ftrace就很迎合，首先是定义了很多的访问接口，更具体的有个instance的目录项，可生成不同的实例，显然是属于用户需考虑的trace策略。基于这样一种思考，提供一个本身就带策略性的工具是不是反而会影响用户策略的定制！ 2/ 实现难度，一是，我们知道内核与用户态的交互，除了时实的系统调用，信息获取基本上偏软的通过/proc，偏硬的通过/sys目录接口（简单这样理解喽）。想整合成便利的工具，其实就是做接口封装，目的就是有效的获取和输入各种tracing信息，但是接口多封装起来就越麻烦。二是，ftrace功能和内核配置相关并采用debugfs挂载使用。动态的功能拓展和使用，工具解析起来自然难度升级，BTW，有时在使用过程中，突然发现/tracing目录被卸载了，又得重新mount一次！

以上主要是观感，因为自己也想过怎么实现一个和内核模块的用户态工具！下面简单说说怎么使用ftrace的，没去做进一步的探索。详见linux内核文档：Documentation/trace

首先是内核配置了：
Kernel hacking —>
[*] Tracers —>
这里写图片描述
我的环境是如上配置，当然还可以增减，尝试过全选系统起来要了将近半小时，建议按需配置！

更新内核后，mount -t debugfs nodev /sys/kernel/debug/即可在debug目录下生成一个tracing目录，该目录下有各种trace文件接口。也可以自启动配置，更新/etc/fstab文件：debugfs /sys/kernel/debug debugfs defaults 0 0

用到的操作命令：

echo 0 > /sys/kernel/debug/tracing/tracing_on    # 每次trace前最好先关一下
echo pid > /sys/kernel/debug/tracing/set_ftrace_pid    # 设置trace的进程
echo function_graph > /sys/kernel/debug/tracing/current_tracer    # 当前的trace类型或说引擎，这里是函数调用,还有wakeup，irqoff等。
#trace过滤设置，这里设置后只trace模块为module_name内定义的函数接口。
echo :mod:module_name > /sys/kernel/debug/tracing/set_ftrace_filter
echo function > /sys/kernel/debug/tracing/set_graph_function    # 设置trace函数
echo 1 > /sys/kernel/debug/tracing/options/block    # 防cat trace阻塞，貌似有点用
echo 2 > /sys/kernel/debug/tracing/max_graph_depth    # 设置调用深度
echo 1 > /sys/kernel/debug/tracing/tracing_on    # 开启trace
cat trace    # 一个ring buffer的打印
cat trace_pipe    # 主要用的它，类似管道读取实时数据，不那么卡流畅些

具体的，还用到了一个trace函数接口：trace_printk，加入到模块代码中，tracing_on置1后会使能打印，方便了追踪定位。

有个疑问？在使用过程中，发现模块内部分函数在available_failter_functions内没有函数记录，无法通过set_graph_function进行trace。猜测模块内部分static局部函数接口与内核本身函数重名，但在多次更改trace模块函数设置成特别函数名也无法trace，难道有模块函数trace数量的限制，模块实例有200左右接口？

这里写图片描述

如上图，简单记录下关注过的：
options：对应于顶层tracing目录下的tarce_options，该项目录下各个文件具有读写权限，使能或失效trace选项。trace_optins会同步更新。
instances：该目录下，执行mkdir创建目录，即可创建了一个单独的ftrace实例。通过这种隔离，可方便用户同步的做其它的trace。
max_graph_depth：显示的函数调用层次。不过默认是0，貌似是尽可能的显示，不做重复的显示或是阻塞了，有些疑问？置为1的话显示一层调用关系。
saved_cmdlines：保存了最近的一些trace，记录以 [ pid 进程名] 方式缓存。
tracing_cpumask：可设置trace的cpu，如16核，默认为ffff，想屏蔽cpu0即可设置fffe。

关注函数运行的耗时：

'$' - greater than 1 second
 '@' - greater than 100 milisecond
 '*' - greater than 10 milisecond
 '#' - greater than 1000 microsecond
 '!' - greater than 100 microsecond
 '+' - greater than 10 microsecond
 ' ' - less than or equal to 10 microsecond.