ftrace:跟踪你的内核函数! | Linux 中国

2018 年 1 月 25 日 Linux中国 译者:qhwdw
ftrace 是一个 Linux 内核特性,它可以让你去跟踪 Linux 内核的函数调用。为什么要这么做呢?好吧,假设你调试一个奇怪的问题,而你已经得到了你的内核版本中这个问题在源代码中的开始的位置,而你想知道这里到底发生了什么?
-- Julia Evans

本文导航
编译自 | https://jvns.ca/blog/2017/03/19/getting-started-with-ftrace/ 
 作者 | Julia Evans
 译者 | qhwdw

大家好!今天我们将去讨论一个调试工具:ftrace,之前我的博客上还没有讨论过它。还有什么能比一个新的调试工具更让人激动呢?

这个非常棒的 ftrace 并不是个新的工具!它大约在 Linux 的 2.6 内核版本中就有了,时间大约是在 2008 年。这一篇是我用谷歌能找到的最早的文档[1]。因此,如果你是一个调试系统的“老手”,可能早就已经使用它了!

我知道,ftrace 已经存在了大约 2.5 年了(LCTT 译注:距本文初次写作时),但是还没有真正的去学习它。假设我明天要召开一个专题研究会,那么,关于 ftrace 应该讨论些什么?因此,今天是时间去讨论一下它了!

什么是 ftrace?

ftrace 是一个 Linux 内核特性,它可以让你去跟踪 Linux 内核的函数调用。为什么要这么做呢?好吧,假设你调试一个奇怪的问题,而你已经得到了你的内核版本中这个问题在源代码中的开始的位置,而你想知道这里到底发生了什么?

每次在调试的时候,我并不会经常去读内核源代码,但是,极个别的情况下会去读它!例如,本周在工作中,我有一个程序在内核中卡死了。查看到底是调用了什么函数,能够帮我更好的理解在内核中发生了什么,哪些系统涉及其中!(在我的那个案例中,它是虚拟内存系统)。

我认为 ftrace 是一个十分好用的工具(它肯定没有 strace 那样使用广泛,也比它难以使用),但是它还是值得你去学习。因此,让我们开始吧!

使用 ftrace 的第一步

不像 strace 和 perf,ftrace 并不是真正的 程序 – 你不能只运行 ftrace my_cool_function。那样太容易了!

如果你去读 使用 ftrace 调试内核[2],它会告诉你从 cd /sys/kernel/debug/tracing 开始,然后做很多文件系统的操作。

对于我来说,这种办法太麻烦——一个使用 ftrace 的简单例子像是这样:

   
     
     
     
  1. cd /sys/kernel/debug/tracing

  2. echo function > current_tracer

  3. echo do_page_fault > set_ftrace_filter

  4. cat trace

这个文件系统是跟踪系统的接口(“给这些神奇的文件赋值,然后该发生的事情就会发生”)理论上看起来似乎可用,但是它不是我的首选方式。

幸运的是,ftrace 团队也考虑到这个并不友好的用户界面,因此,它有了一个更易于使用的界面,它就是 trace-cmd!!!trace-cmd 是一个带命令行参数的普通程序。我们后面将使用它!我在 LWN 上找到了一个 trace-cmd 的使用介绍:trace-cmd: Ftrace 的一个前端[3]

开始使用 trace-cmd:让我们仅跟踪一个函数

首先,我需要去使用 sudo apt-get install trace-cmd 安装 trace-cmd,这一步很容易。

对于第一个 ftrace 的演示,我决定去了解我的内核如何去处理一个页面故障。当 Linux 分配内存时,它经常偷懒,(“你并不是真的计划去使用内存,对吗?”)。这意味着,当一个应用程序尝试去对分配给它的内存进行写入时,就会发生一个页面故障,而这个时候,内核才会真正的为应用程序去分配物理内存。

我们开始使用 trace-cmd 并让它跟踪 do_page_fault 函数!

   
     
     
     
  1. $ sudo trace-cmd record -p function -l do_page_fault

  2.  plugin 'function'

  3. Hit Ctrl^C to stop recording

我将它运行了几秒钟,然后按下了 Ctrl+C。 让我大吃一惊的是,它竟然产生了一个 2.5MB 大小的名为 trace.dat 的跟踪文件。我们来看一下这个文件的内容!

   
     
     
     
  1. $ sudo trace-cmd report

  2.          chrome-15144 [000] 11446.466121: function:             do_page_fault

  3.          chrome-15144 [000] 11446.467910: function:             do_page_fault

  4.          chrome-15144 [000] 11446.469174: function:             do_page_fault

  5.          chrome-15144 [000] 11446.474225: function:             do_page_fault

  6.          chrome-15144 [000] 11446.474386: function:             do_page_fault

  7.          chrome-15144 [000] 11446.478768: function:             do_page_fault

  8. CompositorTileW-15154 [001] 11446.480172: function:             do_page_fault

  9.          chrome-1830  [003] 11446.486696: function:             do_page_fault

  10. CompositorTileW-15154 [001] 11446.488983: function:             do_page_fault

  11. CompositorTileW-15154 [001] 11446.489034: function:             do_page_fault

  12. CompositorTileW-15154 [001] 11446.489045: function:             do_page_fault

看起来很整洁 – 它展示了进程名(chrome)、进程 ID(15144)、CPU ID(000),以及它跟踪的函数。

通过察看整个文件,(sudo trace-cmd report | grep chrome)可以看到,我们跟踪了大约 1.5 秒,在这 1.5 秒的时间段内,Chrome 发生了大约 500 个页面故障。真是太酷了!这就是我们做的第一个 ftrace!

下一个 ftrace 技巧:我们来跟踪一个进程!

好吧,只看一个函数是有点无聊!假如我想知道一个程序中都发生了什么事情。我使用一个名为 Hugo 的静态站点生成器。看看内核为 Hugo 都做了些什么事情?

在我的电脑上 Hugo 的 PID 现在是 25314,因此,我使用如下的命令去记录所有的内核函数:

   
     
     
     
  1. sudo trace-cmd record --help # I read the help!

  2. sudo trace-cmd record -p function -P 25314 # record for PID 25314

sudo trace-cmd report 输出了 18,000 行。如果你对这些感兴趣,你可以看 这里是所有的 18,000 行的输出[4]

18,000 行太多了,因此,在这里仅摘录其中几行。

当系统调用 clock_gettime 运行的时候,都发生了什么:

   
     
     
     
  1. compat_SyS_clock_gettime

  2.    SyS_clock_gettime

  3.       clockid_to_kclock

  4.       posix_clock_realtime_get

  5.          getnstimeofday64

  6.             __getnstimeofday64

  7.                arch_counter_read

  8.    __compat_put_timespec

这是与进程调试相关的一些东西:

   
     
     
     
  1. cpufreq_sched_irq_work

  2.    wake_up_process

  3.       try_to_wake_up

  4.          _raw_spin_lock_irqsave

  5.             do_raw_spin_lock

  6.          _raw_spin_lock

  7.             do_raw_spin_lock

  8.          walt_ktime_clock

  9.             ktime_get

  10.                arch_counter_read

  11.          walt_update_task_ravg

  12.             exiting_task

虽然你可能还不理解它们是做什么的,但是,能够看到所有的这些函数调用也是件很酷的事情。

“function graph” 跟踪

这里有另外一个模式,称为 function_graph。除了它既可以进入也可以退出一个函数外,其它的功能和函数跟踪器是一样的。这里是那个跟踪器的输出[5]

   
     
     
     
  1. sudo trace-cmd record -p function_graph -P 25314

同样,这里只是一个片断(这次来自 futex 代码):

   
     
     
     
  1.             |      futex_wake() {

  2.             |        get_futex_key() {

  3.             |          get_user_pages_fast() {

  4.  1.458 us   |            __get_user_pages_fast();

  5.  4.375 us   |          }

  6.             |          __might_sleep() {

  7.  0.292 us   |            ___might_sleep();

  8.  2.333 us   |          }

  9.  0.584 us   |          get_futex_key_refs();

  10.             |          unlock_page() {

  11.  0.291 us   |            page_waitqueue();

  12.  0.583 us   |            __wake_up_bit();

  13.  5.250 us   |          }

  14.  0.583 us   |          put_page();

  15. + 24.208 us  |        }

我们看到在这个示例中,在 futex_wake 后面调用了 get_futex_key。这是在源代码中真实发生的事情吗?我们可以检查一下!!这里是在 Linux 4.4 中 futex_wake 的定义[6] (我的内核版本是 4.4)。

为节省时间我直接贴出来,它的内容如下:

   
     
     
     
  1. static int

  2. futex_wake(u32 __user *uaddr, unsigned int flags, int nr_wake, u32 bitset)

  3. {

  4.    struct futex_hash_bucket *hb;

  5.    struct futex_q *this, *next;

  6.    union futex_key key = FUTEX_KEY_INIT;

  7.    int ret;

  8.    WAKE_Q(wake_q);

  9.    if (!bitset)

  10.        return -EINVAL;

  11.    ret = get_futex_key(uaddr, flags & FLAGS_SHARED, &key, VERIFY_READ);

如你所见,在 futex_wake 中的第一个函数调用真的是 get_futex_key! 太棒了!相比阅读内核代码,阅读函数跟踪肯定是更容易的找到结果的办法,并且让人高兴的是,还能看到所有的函数用了多长时间。

如何知道哪些函数可以被跟踪

如果你去运行 sudo trace-cmd list -f,你将得到一个你可以跟踪的函数的列表。它很简单但是也很重要。

最后一件事:事件!

现在,我们已经知道了怎么去跟踪内核中的函数,真是太酷了!

还有一类我们可以跟踪的东西!有些事件与我们的函数调用并不相符。例如,你可能想知道当一个程序被调度进入或者离开 CPU 时,都发生了什么事件!你可能想通过“盯着”函数调用计算出来,但是,我告诉你,不可行!

由于函数也为你提供了几种事件,因此,你可以看到当重要的事件发生时,都发生了什么事情。你可以使用 sudo cat /sys/kernel/debug/tracing/available_events 来查看这些事件的一个列表。 

我查看了全部的 schedswitch 事件。我并不完全知道 schedswitch 是什么,但是,我猜测它与调度有关。

   
     
     
     
  1. sudo cat /sys/kernel/debug/tracing/available_events

  2. sudo trace-cmd record -e sched:sched_switch

  3. sudo trace-cmd report

输出如下:

   
     
     
     
  1. 16169.624862:   Chrome_ChildIOT:24817 [112] S ==> chrome:15144 [120]

  2. 16169.624992:   chrome:15144 [120] S ==> swapper/3:0 [120]

  3. 16169.625202:   swapper/3:0 [120] R ==> Chrome_ChildIOT:24817 [112]

  4. 16169.625251:   Chrome_ChildIOT:24817 [112] R ==> chrome:1561 [112]

  5. 16169.625437:   chrome:1561 [112] S ==> chrome:15144 [120]

现在,可以很清楚地看到这些切换,从 PID 24817 -> 15144 -> kernel -> 24817 -> 1561 -> 15114。(所有的这些事件都发生在同一个 CPU 上)。

ftrace 是如何工作的?

ftrace 是一个动态跟踪系统。当我们开始 ftrace 内核函数时,函数的代码会被改变。让我们假设去跟踪 do_page_fault 函数。内核将在那个函数的汇编代码中插入一些额外的指令,以便每次该函数被调用时去提示跟踪系统。内核之所以能够添加额外的指令的原因是,Linux 将额外的几个 NOP 指令编译进每个函数中,因此,当需要的时候,这里有添加跟踪代码的地方。

这是一个十分复杂的问题,因为,当不需要使用 ftrace 去跟踪我的内核时,它根本就不影响性能。而当我需要跟踪时,跟踪的函数越多,产生的开销就越大。

(或许有些是不对的,但是,我认为的 ftrace 就是这样工作的)

更容易地使用 ftrace:brendan gregg 的工具及 kernelshark

正如我们在文件中所讨论的,你需要去考虑很多的关于单个的内核函数/事件直接使用 ftrace 都做了些什么。能够做到这一点很酷!但是也需要做大量的工作!

Brendan Gregg (我们的 Linux 调试工具“大神”)有个工具仓库,它使用 ftrace 去提供关于像 I/O 延迟这样的各种事情的信息。这是它在 GitHub 上全部的 perf-tools[7] 仓库。

这里有一个权衡,那就是这些工具易于使用,但是你被限制仅能用于 Brendan Gregg 认可并做到工具里面的方面。它包括了很多方面!:)

另一个工具是将 ftrace 的输出可视化,做的比较好的是 kernelshark[8]。我还没有用过它,但是看起来似乎很有用。你可以使用 sudo apt-get install kernelshark 来安装它。

一个新的超能力

我很高兴能够花一些时间去学习 ftrace!对于任何内核工具,不同的内核版本有不同的功效,我希望有一天你能发现它很有用!

ftrace 系列文章的一个索引

最后,这里是我找到的一些 ftrace 方面的文章。它们大部分在 LWN (Linux 新闻周刊)上,它是 Linux 的一个极好的资源(你可以购买一个 订阅[9]!)

◈  使用 Ftrace 调试内核 - part 1 [2] (Dec 2009, Steven Rostedt)
◈  使用 Ftrace 调试内核 - part 2 [10] (Dec 2009, Steven Rostedt)
◈  Linux 函数跟踪器的秘密 [11] (Jan 2010, Steven Rostedt)
◈  trace-cmd:Ftrace 的一个前端 [3] (Oct 2010, Steven Rostedt)
◈  使用 KernelShark 去分析实时调试器 [8] (2011, Steven Rostedt)
◈  Ftrace: 神秘的开关 [12] (2014, Brendan Gregg)
◈ 内核文档:(它十分有用)  Documentation/ftrace.txt [13]
◈ 你能跟踪的事件的文档  Documentation/events.txt [14]
◈ linux 内核开发上的一些 ftrace 设计文档 (不是有用,而是有趣!)  Documentation/ftrace-design.txt [15]

via: https://jvns.ca/blog/2017/03/19/getting-started-with-ftrace/

作者:Julia Evans[17] 译者:qhwdw 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

LCTT 译者
qhwdw 🌟 🌟 🌟 🌟
共计翻译: 53 篇
贡献时间:86 天

推荐文章

< 左右滑动查看相关文章 >

点击图片、输入文章 ID 或识别二维码直达




登录查看更多
0

相关内容

模型优化基础,Sayak Paul,67页ppt
专知会员服务
75+阅读 · 2020年6月8日
【2020新书】C++20 特性 第二版,A Problem-Solution Approach
专知会员服务
58+阅读 · 2020年4月26日
【CVPR2020-谷歌】多目标(车辆)跟踪与检测框架 RetinaTrack
专知会员服务
44+阅读 · 2020年4月10日
Python数据分析:过去、现在和未来,52页ppt
专知会员服务
99+阅读 · 2020年3月9日
TensorFlow Lite指南实战《TensorFlow Lite A primer》,附48页PPT
专知会员服务
69+阅读 · 2020年1月17日
【电子书】C++ Primer Plus 第6版,附PDF
专知会员服务
87+阅读 · 2019年11月25日
Python 3.8.0来了!
数据派THU
5+阅读 · 2019年10月22日
Linux挖矿病毒的清除与分析
FreeBuf
14+阅读 · 2019年4月15日
CVPR2019 | SiamMask:视频跟踪最高精度
计算机视觉life
5+阅读 · 2019年3月10日
自定义损失函数Gradient Boosting
AI研习社
13+阅读 · 2018年10月16日
Python | Jupyter导出PDF,自定义脚本告别G安装包
程序人生
7+阅读 · 2018年7月17日
教你用Python来玩跳一跳
七月在线实验室
6+阅读 · 2018年1月2日
AI都干过什么让人细思极恐的事?
全球创新论坛
4+阅读 · 2017年9月15日
Mesh R-CNN
Arxiv
4+阅读 · 2019年6月6日
Arxiv
5+阅读 · 2019年2月28日
Large-Scale Study of Curiosity-Driven Learning
Arxiv
8+阅读 · 2018年8月13日
Arxiv
3+阅读 · 2018年5月21日
Arxiv
6+阅读 · 2018年2月8日
Arxiv
7+阅读 · 2018年1月24日
Arxiv
7+阅读 · 2017年12月26日
VIP会员
相关资讯
Python 3.8.0来了!
数据派THU
5+阅读 · 2019年10月22日
Linux挖矿病毒的清除与分析
FreeBuf
14+阅读 · 2019年4月15日
CVPR2019 | SiamMask:视频跟踪最高精度
计算机视觉life
5+阅读 · 2019年3月10日
自定义损失函数Gradient Boosting
AI研习社
13+阅读 · 2018年10月16日
Python | Jupyter导出PDF,自定义脚本告别G安装包
程序人生
7+阅读 · 2018年7月17日
教你用Python来玩跳一跳
七月在线实验室
6+阅读 · 2018年1月2日
AI都干过什么让人细思极恐的事?
全球创新论坛
4+阅读 · 2017年9月15日
相关论文
Mesh R-CNN
Arxiv
4+阅读 · 2019年6月6日
Arxiv
5+阅读 · 2019年2月28日
Large-Scale Study of Curiosity-Driven Learning
Arxiv
8+阅读 · 2018年8月13日
Arxiv
3+阅读 · 2018年5月21日
Arxiv
6+阅读 · 2018年2月8日
Arxiv
7+阅读 · 2018年1月24日
Arxiv
7+阅读 · 2017年12月26日
Top
微信扫码咨询专知VIP会员