ibm db2获取目标时间与当前时间的差值_Kernel trace tools（二）：内核态执行时间跟踪...

本文是由字节跳动系统部 STE 团队出品的“kernel trace tools”系列文章之一，以介绍团队自研多类延迟问题追踪工具。
在实际工作中，会遇到由于内核态不调度而引发的高网络延迟或者卡顿问题。但是，对于该类问题的定位和追踪缺乏行之有效的方案或客观依据，需要耗费大量时间和精力用于问题排查，trace-noschedule 工具便是在该背景下诞生的自研工具。
目前，trace-noschedule 已开源，感兴趣详见 Open Source Repo：

(https://github.com/bytedance/trace-noschedule)

1. 问题背景

在实际项目实践中，我们经常会遇到延迟高导致的问题。由于我们服务器的内核默认配成内核态不支持抢占，因此不抢占这点也是可能导致问题的原因之一。例如 A 进程陷入内核态执行时间过长，必然影响其他希望在该核运行的进程。此时就会导致调度延迟。针对这种 case，我们开发了一款工具专门跟踪陷入内核态长时间不调度的进程。这对于我们排查问题可以有一定的指导方向。同时如果是此类原因导致的延迟，也可以快速定位问题原因。

2. 我们想做什么

当一个进程陷入内核态时，我们应该记录其时间戳。当离开内核时，再一次记录时间戳。然后求差值即可得到进程在内核态运行的时间。思路比较清晰。

3. 如何实现

我们知道应用程序陷入内核态的方式主要是系统调用。我们是否可以通过系统调用提供的 tracepoint 完成呢？当系统调用开始，记录时间戳，系统调用退出，再次记录时间戳。求差值，就是本次系统调用花费的时间。这种方法是否可靠？很明显不可靠。因为进程在内核态很可能由于资源不满足导致主动 schedule。这种情况下，根本不是一直占用 CPU 不调度的情况。因此，这种方法不可行。

既然系统调用这条路走不通，我们就换一种方式。我们知道一个线程执行的生命周期，起于 schedule，止于 schedule。所以我们可以知道一个线程从开始执行到主动或被动放弃 CPU 之间的时间差。这部分时间是总时间，即 user+kernel 的时间。我们是否有办法获取总时间呢？很幸运我们有 schedule 的 tracepoint 可以获取。

static void __sched notrace __schedule(bool preempt)
{
    
    /* ... */
    trace_sched_switch(preempt, prev, next);
    /* ... */
}

我们只需要 enable sched_switch 即可获取每个线程执行的总时间。是不是激动的心，颤抖的手，是不是马上想用 bcc 行动了？但是有个新的问题摆在我们面前，如何过滤掉 user 态执行的时间？因为用户态支持抢占，内核态不支持抢占。所以统计内核态的时间才是有意义的。

过滤用户态执行时间可以间接的通过定时器实现。我们知道周期性定时中断，可以获取被打断的上下文是用户态或者内核态。所以开始时间戳 last 需要不断的更新。第一次是从 schedule 开始，后面每次更新是在定时器中断中，如果发现当前中断是打断的用户态，那么更新 last 时间戳，否则不更新。此刻认为用户线程在内核态执行。我们看下示例代码。

static enum hrtimer_restart trace_nosched_hrtimer_handler(struct hrtimer *hrtimer)
{
    
        /*
         *