分析内核代码覆盖率方法|内核调试之分析内核代码覆盖率检测技巧

分析内核代码覆盖率

获得足够的内核覆盖率是系统压力测试的另一个职责。尽管所选的测试组合充分地利用了四种主要资源，它也有可能只是执行了内核的一小部分。因而，您应该对覆盖率进行分析以确保组合可以成为一个系统压力测试，而不是一个系统负载生成器。当前，有两个开放源代码工具可以帮助进行 Linux 内核的代码覆盖率分析：

gcov：一个由 Linux Test Project 维护的开放源代码工具。这个工具分析内核代码的覆盖率，并报告哪些行、函数和分支被覆盖以及它们被访问了多少次。

lcov：另一个由 IBM 开发，由 Linux Test Project 维护的开放源代码工具。这个工具由一组构建于基于文本的 gcov 输出之上的 Perl 脚本构成，以实现基于 HTML 的输出。输出包括覆盖率百分比、图表以及概述页，可以快速浏览覆盖率数据。您可以自 Linux Test Project（LTP）主页找到这两个工具（参阅 参考资料以获得链接）。

gcov 模块加载以后，所有运行于系统压力测试组合中的测试都必须执行。尽管原来的系统压力测试可以同时执行，也应该同时执行，但是这次运行应该是循环进行的。每个测试都应该运行一次直到结束，一个接一个地运行，不能重复运行任何测试。单个地、循环地运行，是为了减少在同时运行多个系统压力测试时，内核尝试去平衡它们的负载而导致的不可预知的和无目的的内核代码执行。您应该在最后一个测试运行结束后再进行 gcov 分析。由于最终是要格式化数据以进行分析，所以运行 lcov 工具并缷载 gcov 模块。

lcov 工具会生成一棵完整的 HTML 树，其中包含有内核中代码的每一行以及关于每一行执行了多少次的数据（如果有的话）。这个工具会量化覆盖率数据并生成关于内核中每一部分和文件覆盖率的百分比数字。下面的例子展示了一个示例性的代码覆盖率输出：

lcov 维护者定义了“足够的覆盖”（绿色的），因而这个 lcov 示例仅仅是一种评价。不过，所包括的原始数据让任何浏览者都可以做出他或她自己的判断。在浏览了覆盖率分析后，测试创建者现在可以修改测试的组合，以改变和/或 增加所覆盖的代码的数量。

评价最终压力测试

之所以要执行方法中的这最后一步，是为了对系统压力测试进行核实。在一个被认为是稳定的内核上执行压力测试；通常，发行版本中的内核可以满足这一要求，但不总是如此。要长时间地执行压力测试（推荐至少 24 个小时），同时运行 sar 工具，原因有以下两点：

长时间运行有助于发现组合中的所有问题，否则，在短时间的“取样测试（sniff test）”中这些问题可能会被忽略。

sar 生成的数据构成以后测试运行中进行比较的基线。

长时间运行结束后，您现在可以基于收集的所有数据来决定这个测试组合是否是系统压力测试的合适候选者。

Linux Test Project 在设计 Linux 内核压力测试脚本 ltpstress.sh 时使用了这一设计方法。这个应用程序组合了来自 LTP 的测试套件不同方面的多个测试以及内存和网络传输负载生成器。在执行之前，测试会根据系统中存在多少物理和虚拟内存来调整其总的内存使用情况。这个测试脚本可以自 LTP 测试套件获得（见 参考资料）。为了确保结果的准确性，这个脚本创建于受控的实验室条件下。

IBM Linux Technology Center Test 部门使用这个压力测试以及其他工具和测试作为帮助确认 Linux 内核发行版本稳定性的一个相对快速和简便的途径。为帮助确保得到足够的覆盖率，测试既在实验室条件下也在模拟的用户情形下进行。