linux中断采样时间,Kernel trace tools（一）：中断和软中断关闭时间过长问题追踪...

目前，trace-irqoff 已开源，如感兴趣详见 Open Source Repo( https://github.com/bytedance/trace-irqoff/tree/master ) 。

在工作中，我们经常遇到业务的进程网络延迟高。基于此前分析同类问题的丰富经验，造成上述问题的原因有很多种。我们发现以下两种原因经常出现在我们的视野中。

hardirq 关闭时间过长。

softirq 关闭时间过长。

hardirq 关闭时间过长会导致调度延迟，本地 CPU 的 softirq 也会因得不到执行。我们知道网络收发包就是使用 softirq，因此 hardirq 关闭时间过长必然导致问题。同样，softirq 关闭是一样的，虽不会影响 hardirq，但是它直接影响了 softirq 的执行。

2. 我们需要什么

每一次为了确认是否以上原因导致问题，我们经常需要浪费很多的时间。因此有必要开发一款工具专门可以定位这种原因导致的网络延迟问题。我们并不是只求案发现场，我们还要抓住元凶。我们需要知道哪个进程在代码什么位置关闭中断，这很有助于我们高效地解决问题。

3. 是否有现成的方案

我们的目的很简单，跟踪 hardirq/softirq 关闭时间。我们有什么办法做到呢？最简单直观的方法应该是在内核开关中断的地方加入 hook 函数，统计开关时间戳即可得到差值，差值即关闭时间。Linux 内核提供打开关闭中断的 API 如下：

/* hardirq enable/disable api */

local_irq_disable

local_irq_enable

local_irq_save

local_irq_restore

/* softirq enable/disable api */

local_bh_disable

local_bh_enable

没错，hardirq 关闭跟踪 Linux 内核中已经有现成的实现方案，我们只需要配置以下 config 选项即可。

CONFIG_IRQSOFF_TRACER=y

好了，似乎我们什么都不用做直接使用即可。看起来是这样的，但是这里存在 2 个问题。

CONFIG_IRQSOFF_TRACER 默认是关闭的，如果需要这么做我们需要重新编译内核，还要重装，最后等待问题复现。这不是我们想要的。

Linux 内核里面中断开关频繁。即使方案可行，overhead 也会很高。所以再一次不是我们想要的。

CONFIG_IRQSOFF_TRACER 默认是关闭的，如果需要这么做我们需要重新编译内核，还要重装，最后等待问题复现。这不是我们想要的。

Linux 内核里面中断开关频繁。即使方案可行，overhead 也会很高。所以再一次不是我们想要的。

我们换一个思路。我们可以利用 hrtimer 判断两次中断之间的时间来判断是否关闭了中断。hrtimer 是 Linux 中的高精度定时器，并且执行上下文是 hardirq。所以可以基于这种方式，虽然不够精确但是足以满足我们的需求。例如，hrtimer 定时周期是 10ms。那么两次中断之间的时间间隔应该是 10ms。如果某次发现两次采样时间间隔是 50ms，可以间接说明关闭中断约 50ms。另外根据采样定理，两次中断之间的时间间隔必须大于 2 倍采样周期(20ms)才能认为中断关闭。所以我们的方法比较明确了，针对每个 CPU 都会启动一个 hrtimer，并且绑定每个 CPU。在 hrtimer handle 里面计算中断时间间隔。这就做到了中断关闭检测了。softirq 该怎么办呢？我们可以如法炮制。在 Linux 内核中，普通定时器 timer 执行上下文就是 softirq。很符合我们需求。所以我们可以按照类似的方法周期性采样，只不过定时器使用的是普通 timer。

5. 记录元凶的栈

当我们发现两次中断时间间隔大于阈值时，我们需要知道当前 CPU 究竟在做什么，导致 hardirq/softirq 被关闭。我们可以在中断处理函数中记录当前 CPU 的栈。这么做的前提是，中断处理函数执行时，当前进程不能发生调度，也就是元凶必须在现场。可谓是"抓个现行"。

5.1 hardirq

针对 hardirq 关闭情况。当进程在关闭和打开中断之间发生了定时器中断