首先让我们看看如何评估 Linux 驱动程序的实现。需要注意的是，Linux 版的Tracealyzer充分利用了 LTTng，这是一个开源跟踪器和分析器，它允许开发人员通过解析 LTTng 的输出并生成可视化和详细统计信息来评估内核的性能。
Fig1_Device-Block-Diagram-MAB Labs
图 1. 自定义 Linux 驱动程序。
为其评估驱动程序的设备具有三个主要接口。I2C 接口控制设备，SPI 接口用于将数据流回 Linux 设备，GPIO 是一条中断线，用于指示何时有数据准备好消费。当 GPIO 线被断言时，驱动程序发送一个 I2C 命令来指示设备开始流式传输，这将通过 SPI 接口完成。驱动程序会指示嵌入式 Linux 系统中的 DMA 控制器（DMAC）管理 SPI 总线和系统 RAM 之间的数据传输，以确保 CPU 能够管理其他任务。最后，Linux 设备上存在应用程序代码，用于从 RAM 检索流数据并将其存储在非易失性存储器中。
Tracealyzer 用于验证两个重要指标。首先，从 GPIO 被断言到 I2C 命令发出的时间量保持在最短。其次，Linux 内核为驱动程序提供了足够的执行周期，使其能够定期管理 DMAC 遇到的任何问题。目标是保证流传输过程中丢失的数据最少，Tracealyzer 用于帮助确保这一保证。
设备开发套件
Tracealyzer 使用 LTTng 生成的文件，因此通过在设备的基于 Yocto 项目的板级支持包 (BSP) 中创建自定义层，嵌入式 Linux 平台被配置为支持 LTTng。生成的 Linux 映像加载到 SD 卡上并在开发套件上启动。加载设备驱动程序并将生成的跟踪数据存储在卡上以供离线分析。然后在主机上启动 Tracealyzer 以查看和分析收集的跟踪。
为了研究内核空间，“跟踪视图”、“参与者实例”、“CPU 负载图”和“上下文切换强度”视图是最合适的。跟踪视图（图 2）显示了内核中使用的交换器（空闲任务）在整个捕获期间占用了最多的执行资源，这是预期的。当驱动程序正在运行并将数据从设备传输到开发板时，特定的内核线程会获得平台上更大的执行资源块来执行传输。
下一个重要的视图是actor 实例。在下拉菜单中选择“执行时间”会生成一个图表，指示任何特定“参与者”（定义为任何执行元素，例如线程或进程）占用的时间量。选择一个内核线程会显示其执行时间在 350、450 和 550 微秒处出现一些峰值。要了解这些尖峰是否真正值得关注，我们需要了解系统的时序要求，或者将其与系统在“正常”条件下的运行情况进行比较。
从跟踪中选择另一个内核线程会显示其中一个内核线程的执行时间出现相对较大的峰值。“CPU 负载”视图描述了不同参与者的 CPU 利用率。我们可以看到，突出显示的内核线程执行时间的峰值并没有导致 CPU 利用率异常高（最大 CPU 利用率略高于 1%）。因此，该峰值无需担心。
最后一个视图是“上下文切换强度”视图，它显示内核驱动程序是否具有性能并且不会导致内核抖动。
相对于其他线程，这不会显示任何特定内核线程的任何重要上下文切换。如果驱动程序中存在性能问题，则内核线程可能存在重要的上下文切换。这可能是由于内核调度程序将执行时间分配给内核线程，然后在一段时间后移动到另一个线程，但如果它需要执行资源，则立即切换回该线程。同样，大约 20 次上下文切换是否可接受的确定取决于系统要求或系统正常运行时执行的测量。
这些视图还提供了一种快速的方式来概览跟踪和定位“热点”或感兴趣的异常以供进一步研究。这是 Tracealyzer 的主要优点之一，否则很难在包含数千甚至数百万个事件的长跟踪中找到它们。
发现 Linux 中断处理程序中的性能问题
大多数 Linux 设备驱动程序使用中断。关于中断要记住的第一件事是限制分配给中断处理程序的操作数量很重要，因为内核处于敏感状态，整个处理器也是如此。举个例子，当中断处理程序运行时，所有的中断都被屏蔽了——也就是说没有其他中断可以触发；如果一个中断处理程序执行了很长时间，可能会错过其他中断。因此，在处理中断（例如寄存器操作和在处理器内存中移动数据）时，必须坚持最低限度。管理其他操作（例如数据传输）应委托给小任务或其他内核机制。在驱动程序示例中，设备规范规定将中断设置为每 80 毫秒触发一次，
知道什么时候打印
Tracealyzer 可用于确保中断处理程序尽可能少地执行操作。例如，它几乎消除了使用 printk 语句、比较内核日志中的时间戳以及遍历无休止的 LTTng 跟踪来评估性能的所有需要。相反，它提供了中断处理程序的清晰和详细视图。
在数据采集设备中，GPIO 信号通知驱动程序已准备好从设备收集数据，驱动程序中的 printk 调用只是在内核日志中记录接收到中断，返回值 IRQ_HANDLED 通知内核中断被处理。
然而，在加载内核模块和连接设备之前，LTTng 在目标设备中启动并指示只捕获中断处理程序。将 LTTng 跟踪传输到主机并启动 Tracealyzer 后，actor 实例图仅显示中断处理程序和相关信息，以便获得更多关注。一眼看去，我们可以显示中断处理程序被触发的频率（在本例中大约是预期的 80 微秒）。但是，通过“选择详细信息”窗口深入挖掘并打开“执行时间”选项会发现中断处理程序执行实例平均需要 3.3 毫秒。
当 printk 调用被删除，actor 实例图显示，视图仍然设置为“执行时间”时，Tracealyzer 显示处理时间显着下降，从使用 printk 时的 3.3 毫秒减少到不使用 printk 时的 14 微秒。
这种差异清楚地说明了 printk 调用中涉及的大量处理，在打印到内核日志时必须考虑各种不同的情况。因此，为了获得最佳性能，显而易见的结论是尽量避免在中断处理程序中使用 printk 或其任何派生类。
Tracealyzer 还表明，执行时间往往会不规律地变化。虽然微秒差异确实很小，但了解为什么会出现这种差异仍然很重要。
虽然捕获的中间部分显示中断处理程序按预期每 80 毫秒触发一次，但在开始和结束时记录的调用数量要高得多。在捕获结束时事情变得非常不稳定，在一个实例中，在 325 毫秒后调用执行。
这可能是因为中断处理程序中的设备没有被指示停止触发其中断。由于中断始终存在，Linux 调度程序不断将执行资源返回给中断处理程序；这种不利的现象通常被称为“颠簸”，但 printk 语句掩盖了该错误。
有趣的是，即使没有指示设备停止调用中断，中断处理程序的周期性也会在一段时间后再次稳定下来。仔细查看设备规范会发现设备上存在故障安全机制，如果未通过 I2C 总线确认，该机制会在一段时间后自动取消断言中断。由于在本示例中执行中断处理程序与 printk 之间的时间约为 80 毫秒，因此执行时间进入取消断言阶段，掩盖了代码未充分取消断言中断的事实。
如果不使用 Tracealyzer，此错误将被有效地隐藏，并且直到发布前不久移除无关的 printk 调用时才会被发现或表现出来。在那个后期阶段，必要的驱动程序修改会导致严重的延迟和成本。
评估 Linux 系统性能
Tracealyzer 还可用于调整 Linux 系统以最大化性能；我们将使用 Linux 系统（例如 Nvidia 的 Jetson Nano）和用户空间应用程序（例如 iperf）来说明这一点。
调整 Jetson Nano 上 iperf 服务器的 CPU 亲和性揭示了该参数如何影响客户端和服务器之间的整体吞吐量。术语 CPU 亲和性表示固定执行上下文的特定 CPU 内核。通常，亲和力是根据应用程序设置的。如果中断和相应处理程序的 CPU 亲和性与数据包接收过程的 CPU 亲和性相匹配，则应将丢包降至最低，因为在内核之间移动数据不会浪费时间 - 至少这是想法。
这种分析和可能的优化首先需要确定 Jetson Nano 上以太网接口 (eth0) 的亲和性。这将指示哪个处理器内核处理来自 eth0 接口的中断。通过不允许 Linux 选择处理器内核，而是将 iperf 服务器执行固定到特定内核，Mohammed 旨在评估对吞吐量的影响。由于 CPU0 负责处理来自 eth0 接口的中断，因此他将 iperf 服务器固定到 CPU3。
从主机运行 iperf 测试，然后停止并销毁 LTTng 会话，以避免产生大量带有无关事件的跟踪。
当 iperf 固定到 CPU3 时，这会在捕获中提供一些有趣的结果。首先，Tracealyzer 显示有四个 iperf 进程正在运行，尽管 Linux 只列出了一个实例。但是Linux上报的PID对应的iperf实例只执行了两次：一次在iperf测量的开始，一次在结束。
即使 iperf 固定到 CPU3，还有其他 iperf 实例在不同的 CPU 内核上执行。这实际上并不少见，因为应用程序可以实现自己的逻辑来选择合适的 CPU 来执行。看来 iperf 也实现了这样的逻辑。
跟踪还显示了与 iperf 实验几乎同时执行的 eth0 中断处理程序的一系列执行实例，显示了 eth0 中断处理程序执行时间和 iperf 实例执行时间之间的相关性。
Tracealyzer 显示从 eth0 中断处理程序完成到 iperf 实例开始执行需要 55 微秒。当系统在所有 CPU 上有 20 个进程负载时，新的 iperf 测量显示吞吐量保持不变。
打开 Tracealyzer 并通过人为强调的 CPU 内核捕获显示中断处理程序和 iperf 实例的执行顺序，eth0 中断处理程序执行完成和 iperf 执行开始之间的时间大约为 40 微秒。
虽然数字本身并不重要（尽管有趣的是，负载下的时间实际上更少），但系统负载时与非负载时的数量级相同 – 40 微秒与 55 微秒。这是一个Linux 内核的巨大特性，即使用户空间应用程序似乎占用了系统的所有四个内核，它仍然可以确保其他用户空间应用程序不会因 CPU 资源而匮乏，并且内核间的通信不受影响。
分析正常和艰苦条件下不同执行元素之间的交互显示了 Linux 内核的一个巧妙特性，即尽最大努力为所有进程提供公平的 CPU 资源共享。
相关实战：https://www.99qibang.cn/information/d51a3036c1ed439a9337d7c1074f5819.html
https://www.99qibang.cn/information/ef576469115f42219928155d81318178.html
https://www.99qibang.cn/information/4d332071e0d342ce836f658e4cc097b0.html
https://www.99qibang.cn/information/55926d4ddae4467098af57499661a841.html
