利用
基于硬件的跟踪功能猎杀 Linux 时间消耗者
作者：R. Dienstbeck, F. Berat - Fa.ADIT
发布日期
2018 年 11 月 27 日
关于公司
高级驾驶员信息技术有限公司（ADIT）
地点
德国希尔德斯海姆
公司规模
67 名员工（截至 2021 年 1 月）
行业
汽车
分析目标系统的运行时行为
分析目标系统运行时行为的能力是调试过程中非常重要但又经常被忽视的一部分。在实时系统中，迟来的答案往往和错误的答案一样糟糕。 答案一样糟糕。各种软件工具，尤其是 Linux 领域的软件工具，可以帮助测量嵌入式系统的性能，但有时这些工具最终会使问题变得更加复杂。本文介绍了位于希尔德斯海姆的Advanced Driver Information Technology GmbH (ADIT) 公司如何使用 Lauterbach'sTRACE32 （一种基于硬件的非侵入式跟踪工具）来解决这个问题。
下一代驾驶舱系统的创造者
在各种解决方案中，ADIT 在Arm 和英特尔处理器上都部署了 Linux ，并利用 SystemTap 来测量整体系统性能，以便找到并消除任何瓶颈。SystemTap 利用了一些很好的 Linux 功能（称为 uprobe 和 kprobe），允许用户分别创建用户级和内核级函数的动态跟踪。
产品
- 覆盖操作系统
- Hypervisor 技术
- 汽车产品的中间件级组件
在Arm 设备上，调用一次上衣所需的时间是原来的两倍。
在轻度到中度的系统负载下，没有出现真正的问题，预计 SystemTap 这样的软件工具对整个系统的实时性能影响不大。出乎意料的是，在基于Arm 的平台 上，系统的运行速度比基于英特尔的平台慢得多 。
为了确认问题所在，我们创建了一个假函数，并对 uprobe 进行了测量。结果显示，在Arm 设备上调用 uprobe 一次所需的时间是原来的两倍。由于 uprobe 在内部使用了 kprobe，最初的怀疑是 kprobe 是罪魁祸首。但这是错误的，因为 kprobe 在Arm 处理器上的运行速度实际上比英特尔处理器快：很明显，问题出在 uprobe 代码上。
由于问题出在软件跟踪代码中，因此无法使用软件跟踪来定位问题。
TRACE32 PowerTrace - 我们基于硬件的跟踪工具
ADIT 决定使用具有硬件跟踪功能的TRACE32 PowerTrace。 硬件跟踪功能。基于硬件的 跟踪完全不影响目标的时序、 即使是最小的代码部分，也能进行非常深入的分析。 代码部分进行深入分析。Arm 和英特尔设备都能 提供非侵入式程序流程信息。 对于 Arm和英特尔设备都能提供非侵入式程序流程信息。 而英特尔则将其等同的功能称为英特尔处理器跟踪（Intel Processor Trace (IPT）。
有关代码执行的信息通过一组专用引脚发出。TRACE32 工具连接到这些引脚以收集这些数据，然后对其进行分析，以生成应用程序的功能流程和每个功能的详细时序。
TRACE32 记录并分析完整的程序流程
即使在复杂的环境中，TRACE32 也能记录和分析完整的程序流程，包括用户级应用程序和内核代码。整个系统的功能流将以时序图或函数层次结构的形式重建和统计显示。
显示包括内核和进程在内的整个 Linux 系统的运行情况会产生一个很大的图表，但TRACE32 可以帮助您分析关键部分。这使得 ADIT 的工程师们能够密切关注内核的 kprobe 和 uprobe 部分。
TRACE32 记录并分析完整的程序流程
如果没有实时跟踪，这几乎是不可能发现的；而有了实时跟踪，追踪问题就变得轻而易举了。ADIT 知道了问题所在，并确定主要问题出在内核配置上。 在从另一个平台迁移时，无意中启用了 CONFIG_PREEMPT_TRACE 的临时设置。跟踪结果表明，这导致Arm 上的堆栈解卷，而在英特尔上则是 "无操作"，从而造成了两者之间巨大的性能差异。通过使用TRACE32 的高级分析功能，我们很快发现存在两个瓶颈（见图 1 和图 2）。
最引人注目的是Arm 平台上的 uprobe 调用了四次 preempt_disable()和 preempt_enable()，每次都要检查堆栈帧，大约需要 0.6μs 的时间，总共造成 2.4μs 的延迟。而在英特尔处理器上没有出现这种情况。仅 2.4μs 的单次差异看似不大，但在每秒多次调用 uprobe 的情况下，很快就会产生明显的延迟。深入研究后发现，第二个瓶颈是字符串操作，它是 uprobe 的必要组成部分。由于Arm 和英特尔之间的架构差异，这个问题无论如何也无法解决。
