Oprofile callgraph：系统调用的起源

Question

我一直在使用 oprofile 来尝试找出为什么我的程序在内核中花费如此多的时间。我现在拥有来自内核的符号，但显然我的程序和内核之间没有链接可以告诉我程序的哪些部分花费了这么长时间。

samples  %        image name               app name                 symbol name
-------------------------------------------------------------------------------
  201       0.8911  vmlinux-3.0.0-30-generic vmlinux-3.0.0-30-generic _raw_spin_lock_irq
  746       3.3073  vmlinux-3.0.0-30-generic vmlinux-3.0.0-30-generic rb_get_reader_page
  5000     22.1671  vmlinux-3.0.0-30-generic vmlinux-3.0.0-30-generic default_spin_lock_flags
  16575    73.4838  vmlinux-3.0.0-30-generic vmlinux-3.0.0-30-generic _raw_spin_lock
22469    11.1862  vmlinux-3.0.0-30-generic vmlinux-3.0.0-30-generic __ticket_spin_lock
  22469    99.6010  vmlinux-3.0.0-30-generic vmlinux-3.0.0-30-generic __ticket_spin_lock [self]
  26        0.1153  vmlinux-3.0.0-30-generic vmlinux-3.0.0-30-generic ret_from_intr

我该去哪里？如何发现程序中导致 __ticket_spin_lock 的位置？

Answer 1

Oprofile 获取堆栈样本。您需要做的不是查看它们的摘要，而是实际检查原始样本。如果您花费 30% 的时间在内核中，那么如果您可以看到随机选择的 10 个堆栈样本，那么您可以期望其中的 3 个（或多或少）向您展示如何进入内核的完整原因。核心。

这样，您将看到摘要或调用图不会显示的内容。

如果不清楚：由于__ticket_spin_lock99.6% 的时间都在堆栈上，因此在您查看的每个堆栈示例中，您有 99.6% 的概率会看到您是如何进入该例程的。然后，如果您确实不需要这样做，则可能会获得 250 倍的加速。这就像从四分钟缩短到一秒。采用“正确”或“自动化”方法 - 获得结果。

补充：关于分析器的事情是它们很受欢迎，并且有些具有非常好的用户界面，但可悲的是，恐怕这是“皇帝的新衣”的情况。如果这样的工具没有找到太多需要修复的地方，那么您将会喜欢它，因为它表明（可能是错误的）您编写的代码接近最佳。

有很多帖子推荐这个或那个探查器，但我不能指出任何声称使用探查器可以节省超过一定比例的时间，比如 40%。也许有一些。

我从未听说过首先使用分析器来获得加速，然后再次使用分析器来获得第二次加速，等等。这就是您获得真正加速的方式 - 多重优化。一开始只是一个小性能问题的东西在删除了一个较大的问题后就不再小了。此图显示了如何通过消除六个问题来将加速提高近三个数量级。你不一定能做到这一点，但这难道不值得尝试吗？

对进一步编辑表示歉意。我只是想证明欺骗调用图很容易。红线代表调用堆栈样本。在这里，A1 将所有时间都花在呼叫 C2 上，反之亦然。然后假设您保持相同的行为，但放入“调度”例程 B。现在调用图丢失了 A1 所有时间都花在 C2 上的信息，反之亦然。您可以轻松地将这个示例扩展到多个级别。 你可以说调用树会看到这一点。好吧，这是欺骗调用树的方法。A 将所有时间都花在对 C 的调用上。现在，如果 A 调用 B1、B2...Bn，而这些调用 C，则从 A 到 C 的“热路径”将被分解为多个片段，因此 A 和 C 之间的关系C 被隐藏。 还有许多其他完全普通的编程实践会使这些工具感到困惑，特别是当样本深度为 10-30 级且功能都很小时，但程序员仔细检查适度数量的样本时，这些关系无法隐藏。