kernel - 使用 DTrace 分析 FreeBSD 内核

Question

我正在寻找使用 FreeBSD 改进接口(interface)破坏时间。在我的运行 -CURRENT 的测试机器上销毁数以千计的接口(interface)需要几分钟时间，虽然——不可否认——我的用例可能是一个不寻常的用例，但我想了解是什么让系统花费了这么长时间。
根据我最初的观察，我能够确定大部分时间都花在等待 if_detach_internal() 中的某个地方。所以为了分析这个函数，我想出了下面的 DTrace 脚本:

#!/usr/sbin/dtrace -s

#pragma D option quiet
#pragma D option dynvarsize=256m

fbt:kernel:if_detach_internal:entry
{
        self->traceme = 1;
        t[probefunc] = timestamp;
}

fbt:kernel:if_detach_internal:return
{
        dt = timestamp - t[probefunc];
        @ft[probefunc] = sum(dt);
        t[probefunc] = 0;
        self->traceme = 0;
}

fbt:kernel::entry
/self->traceme/
{
        t[probefunc] = timestamp;
}

fbt:kernel::return
/self->traceme/
{
        dt = timestamp - t[probefunc];
        @ft[probefunc] = sum(dt);
        t[probefunc] = 0;
}

通过连接到 entry 和 return fbt 探测器，我期望获得 if_detach_internal() 调用的每个函数的函数名称和累积执行时间列表(无论堆栈深度如何)，并过滤掉其他任何内容。
然而，我得到的是这样的(破坏 250 个接口(interface)):
callout_when 1676
sched_load 1779
if_rele 1801
[...]
rt_unlinkrte 10296062843
sched_switch 10408456866
rt_checkdelroute 11562396547
rn_walktree 12404143265
rib_walk_del 12553013469
if_detach_internal 24335505097
uma_zfree_arg 25045046322788
intr_event_schedule_thread 58336370701120
swi_sched 83355263713937
spinlock_enter 116681093870088
[...]
自旋锁退出 4492719328120735
cpu_search_lowest 16750701670277714

至少一些函数的时间信息似乎是有意义的，但我希望 if_detach_internal() 是列表中的最后一个条目，没有什么比这更长的时间了，因为这个函数位于我正在尝试的调用树的顶部配置文件。
显然，情况并非如此，因为我还在以看似疯狂的执行时间测量其他功能( uma_zfree_arg()、 swi_sched() 等)。这些结果完全摧毁了我对 DTrace 在这里告诉我的所有其他内容的信任。
我错过了什么？这种方法听起来好吗？

Answer 1

我将在评论前加上我没有在 FreeBSD 上使用 DTrace，仅在 macOS/OS X 上使用的事实。所以这里可能有一些我不知道的特定于平台的东西在起作用。顺便说一句:

我有点不安你使用全局关联数组t .您可能希望使该线程本地化( self->t )，因为就目前而言，如果 if_detach_internal，您的代码可能会产生垃圾结果同时从多个线程调用。

您使用全局dt变量同样危险且线程不安全。这个真的应该是 this->dt无处不在(子句局部变量)。

另一件需要注意的事情是，操作 fbt:kernel::entry /self->traceme/ 不应该导致代码出现问题。将为 if_detach_internal 调用本身。这是因为后面的函数当然匹配通配符，并且 Action 是按照它们在脚本中出现的顺序执行的，所以到了通配符上的谓词entry Action 被检查，非通配符 Action 将设置self->traceme = 1;像这样双重设置时间戳应该不会造成不良影响，但从代码编写的方式来看，您可能没有意识到这实际上是它所做的，如果您进一步更改可能会导致问题。

不幸的是，DTrace 范围规则相当不直观，因为默认情况下所有内容都是全局且线程不安全的。是的，即使在编写了相当多的 DTrace 脚本代码之后，这仍然时不时地困扰着我。
我不知道遵循上述建议是否可以完全解决您的问题；如果没有，请相应地更新您的问题并在下面给我留言，我会再看一下。