评估基于 Yocto 的 Linux 系统的性能

绝大多数嵌入式 Linux 软件开发人员编写用户空间应用程序。由于这些应用程序特定于某个领域并且非常复杂，因此应用程序开发人员需要一种简单的机制来验证其应用程序的功能并衡量性能。

跟踪点是 LTTng 用户空间跟踪库提供的特定于应用程序的检测点，用于将用户指定的数据捕获为事件，它可实现此目的。跟踪点可以通过两种方式创建：第一种称为 tracef，是一种非常简单的方法，可将所有数据捕获为单个事件。第二种允许开发人员创建自定义事件。虽然后一种机制需要编写更多代码，但它也为收集数据并将其显示在 Tracealyzer 中提供了最大的灵活性。

我在这里使用了 tracef 方法，但请注意，这也会捕获内核跟踪，原因有二。首先，包含内核跟踪通常可以解释用户空间事件的时间线。例如，如果我们应用程序中的两个事件之间存在较长的延迟，则内核事件应该可以显示导致延迟的原因。其次，从 4.4.2 版开始，Tracealyzer 需要内核跟踪中的一些数据才能正确显示 UST 事件，尽管它不需要是完整的内核跟踪。

Tracealyzer 还可以测量用户空间应用程序的性能。此特定示例使用 Linux usleep 函数模拟需要一定时间的函数，在函数调用之前添加一个跟踪点，并在之后添加另一个跟踪点，以测量函数完成所需的时间。

在实际场景中，开发人员会确定应用程序中需要测量执行时间的位置，并在那里添加 tracef 调用。例如，一个函数可能有多个实现候选，并且会检查执行时间以找到最快的算法。或者特定函数可能很复杂，需要对执行进行表征。编译上述应用程序、在目标上启动 LTTng 会话、捕获和下载生成的跟踪数据后，在 Tracealyzer 中检查跟踪数据。

图 1.放大跟踪视图来检查跟踪数据。

usleep 函数调用的执行时间可以定义为每对“开始”和“停止”事件之间的时间。在 Tracealyzer 中执行此操作的最佳方法是为自定义用户事件创建间隔。

保存自定义间隔定义后，它将出现在间隔和状态机窗口中，并且 Tracealyzer 会在跟踪视图中突出显示它，从而允许生成间隔时序图。

图 2. 要绘制间隔时间图，请在视图菜单中选择设置...。

毫不奇怪，所有间隔执行似乎都持续了大约 25 毫秒，但单击其中一个数据点就会显示有关该间隔的有价值的时间信息。

图 3. 时间信息视图。

Tracealyzer 显示每个间隔长度的统计数据，这与相关函数的执行时间相对应。第二个框显示我们感兴趣的函数执行间隔时间的统计数据，例如停止事件和下一个启动事件之间的时间。第三个框显示每个间隔发生的频率，即从启动到下一个启动测量的时间。

区间图可用于识别感兴趣的函数的任何异常时间，并且选择详细信息视图中的信息可用于收集高级时间统计数据。

大多数嵌入式软件开发人员将在基于 Linux 的嵌入式系统上开发用户空间应用程序。Tracealyzer 与 LTTng 跟踪点结合使用，可以成为一种非常有用的工具，用于确定应用程序的运行情况、识别任何异常行为并提供高级时序统计数据。然后，它可用于进一步排除任何时序问题并提高应用程序的性能。

了解编译器选项对性能的影响

编译器选项会影响最无害的计算的性能，即使是基本的正弦函数也是如此。使用 Tracealyzer 可以帮助开发人员了解这些选项如何影响执行更复杂计算的用户空间应用程序的性能。

我已经能够通过计算频率为 100 Hz、采样率为 1 kHz 的正弦波的 1000 个点来证明这一点。通过使用“标准”编译器选项，我们在 Tracealyzer 中查看系统时间时会看到跟踪中的不连续性。在将每个样本打印到文件的代码片段中添加 printf 调用不会显示不连续性，因为这只是将值打印到文件中，没有任何时间概念。但是，当将计算出的值输出到跟踪文件时，系统时间包含在每个跟踪值中。

更改编译器中的选项有助于减少这种不连续性。标准 CPU(例如 Arm 处理器)的架构旨在高效执行整数运算而不是浮点运算，因此编译器将浮点指令转换为一系列基于整数的指令。这会导致 CPU 执行的指令数量大幅增加，系统中的另一个任务有更大的机会抢占正弦波计算。Tracealyzer 中的跟踪视图证实了这一点，其中负责正弦波计算的进程确实被其他进程抢占，在最坏的情况下暂停 900 微秒。

图 4. 使用整数处理浮点应用程序的不连续性。

为编译器指定“-mfloat-abi=hard”选项会告诉它使用一组专门为浮点操作设计的指令。然而，这并没有产生任何真正的差异，因为仍然存在不连续，迹线视图显示正弦波过程暂停相同的时间-900 ms。

这是因为这些浮点指令有特定的扩展，可以在处理器本身上有一个单独的、高度优化的浮点单元(FPU)。这需要为编译器指定“fpu”选项。“-mfloat-abi=hard”选项允许编译器自由地选择适当的扩展。

添加“-mfpu=neon”选项指示编译器为该特定 FPU (NEON) 启用一组特定的扩展。由于大多数浮点计算都在单独的协处理器上运行，因此其他进程几乎没有机会抢占正弦波生成，从而导致不连续性大大减小。

自定义间隔

Tracealyzer 还可以使用自定义间隔直观显示每次正弦计算所需的时间。无需使用带有计算出的正弦值的 tracef 调用，跟踪“开始”和“停止”用户事件即可跟踪计算。

在不使用“float_abi=hard”编译器选项的情况下编译和运行应用程序表明，虽然函数的大部分执行时间大约需要几十微秒，但也存在一些异常值。在一个案例中，该函数执行时间约为 200 微秒，而在另一案例中，执行时间约为 1.05 毫秒!

添加硬 ABI 选项(但不是 NEON 扩展)显示 100-200 微秒范围内的异常值和一次几乎花费 1.1 毫秒的调用。

打开在应用程序编译为使用硬 ABI 和 NEON 扩展时收集的跟踪信息，显示最长执行时间现在略少于 240 微秒。这突出显示了使用 NEON 扩展可以显著减少计算点之间的最差延迟。

使用 LTTng 库和 Tracealyzer，开发人员可以看到某些编译器选项如何影响执行浮点计算的用户空间应用程序的性能。通常，这种分析是在事后进行的，当应用程序完成但观察到的性能被视为不可接受时，这需要大量时间。我们已经能够证明，通过在开发阶段使用 Tracealyzer 等可视化跟踪诊断工具来验证软件时序，可以更早地发现和解决问题。从经验丰富的开发人员的角度来看，这可以避免隐藏的错误，并在项目后期节省时间和成本。