使用 OProfile for Linux on POWER 识别性能瓶颈

使用 OProfile for Linux on POWER 识别性能瓶颈
2011年06月16日
　　使用 OProfile for Linux on POWER 识别性能瓶颈
　　作为一名开发人员，在试图提高代码效率时，您可能发现性能瓶颈是您要面对的最困难的任务之一。代码分析（code profiling）是一种可以使这项任务变得更容易的方法。代码分析包括对那些表示运行系统上的某些处理器活动的数据样本进行分析。OProfile 为 POWER 上的 Linux 提供了这种解决方案。OProfile 被包含在最新的 IBM?? 支持的 Linux for POWER 发行版本中：Red Hat Enterprise Linux 4 (RHEL4) 和 SUSE LINUX Enterprise Server 9 (SLES9)。本文将介绍 OProfile for Linux on POWER，并提供两个例子，演示如何使用它来发现性能瓶颈。
　　回页首 
　　代码分析概述
　　OProfile for Linux on POWER 使用了一个内核模块和一个用户空间守护进程，前者可以访问性能计数寄存器，后者在后台运行，负责从这些寄存器中收集数据。在启动守护进程之前，OProfile 将配置事件类型以及每种事件的样本计数（sample count）。如果没有配置任何事件，那么 OProfile 将使用 Linux on POWER 上的默认事件，即 CYCLES，该事件将对处理器循环进行计数。事件的样本计数将决定事件每发生多少次计数器才增加一次。OProfile 被设计成可以在低开销下运行，从而使后台运行的守护进程不会扰乱系统性能。
　　OProfile 具有对 POWER4??、POWER5?? 和 PowerPC?? 970 处理器的内核支持。PowerPC 970 和 POWER4 处理器有 8 个计数寄存器，而 POWER5 处理器有 6 个计数寄存器。在不具备 OProfile 内核支持的架构上使用的则是计时器（timer）模式。在这种模式下，OProfile 使用了一个计数器中断，对于禁用中断的代码，OProfile 不能对其进行分析。
　　回页首 
　　OProfile 工具
　　与 OProfile 内核支持一起提供的还有一些与内核交互的用户空间工具，以及分析收集到的数据的工具。如前所述，OProfile 守护进程收集样本数据。控制该守护进程的工具称作 opcontrol。表 1 列出了用于 opcontrol 的一些常见的命令行选项。本文的后面还将描述 opreport 和 opannotate 这两个工具，它们都是用于分析收集到的数据的工具。在 OProfile 手册的第 2.2 节中，可以找到对所有 OProfile 工具的概述。（请参阅参考资料。）
　　RHEL4 和 SLES9 上支持的处理器事件类型是不同的，正如不同 POWER 处理器上支持的事件类型也会有所变化一样。您可以使用 opcontrol 工具和 --list-events 选项获得自己平台所支持的那些事件的列表。
　　表 1. opcontrol 命令行选项
　　opcontrol 选项  描述  
　　--list-events 列出处理器事件和单元屏蔽（unit mask）  
　　--vmlinux= 将要分析的内核镜像文件 
　　--no-vmlinux 不分析内核 
　　--reset 清除当前会话中的数据 
　　--setup 在运行守护进程之前对其进行设置 
　　--event= 监视给定的处理器事件 
　　--start 开始取样 
　　--dump 使数据流到守护进程中 
　　--stop 停止数据取样 
　　-h 关闭守护进程 
　　回页首 
　　OProfile 例子
　　您可以使用 OProfile 来分析处理器周期、TLB 失误、内存引用、分支预测失误、缓存失误、中断处理程序，等等。同样，您可以使用 opcontrol 的 --list-events 选项来提供完整的特定处理器上可监视事件列表。
　　下面的例子演示了如何使用 OProfile for Linux on POWER。第一个例子监视处理器周期，以发现编写不当、会导致潜在性能瓶颈的算法。虽然这是一个很小的例子，但是当您分析一个应用程序，期望发现大部分处理器周期究竟用在什么地方时，仍可以借鉴这里的方法。然后您可以进一步分析这部分代码，看是否可以对其进行优化。
　　第二个例子要更为复杂一些 -- 它演示了如何发现二级（level 2，L2）数据缓存失误，并为减少数据缓存失误的次数提供了两套解决方案。
　　例 1： 分析编写不当的代码
　　这个例子的目的是展示如何编译和分析一个编写不当的代码示例，以分析哪个函数性能不佳。这是一个很小的例子，只包含两个函数 -- slow_multiply() 和 fast_multiply() -- 这两个函数都是用于求两个数的乘积，如下面的清单 1 所示。
　　清单 1. 两个执行乘法的函数
　　int fast_multiply(x,  y) 
　　{
　　return x * y;
　　}
　　int slow_multiply(x, y) 
　　{
　　int i, j, z;
　　for (i = 0, z = 0; i
　　在这个例子中，您将查看这个数据结构（如清单 4 所示），并分析两个处理器同时修改这个数据结构时出现的情景）。然后观察数据缓存失误，并考察用来修正这个问题的两种解决方案。
　　清单 4. 共享的数据结构
　　struct shared_data_struct {
　　unsigned int data1;
　　unsigned int data1;
　　}
　　清单 5 中的程序使用 clone() 系统调用和 VM_CLONE 标志生成一个子进程。VM_CLONE 标志会导致子进程和父进程在同一个存储空间中运行。父线程修改该数据结构的第一个元素，而子线程则修改第二个元素。
　　清单 5. 演示 L2 数据缓存失误的代码示例
　　#include 
　　#include 
　　struct shared_data_struct {
　　unsigned int data1;
　　unsigned int data2;
　　};
　　struct shared_data_struct shared_data;
　　static int inc_second(struct shared_data_struct *);
　　int main(){
　　int i, j, pid;
　　void *child_stack;
　　/* allocate memory for other process to execute in */
　　if((child_stack = (void *) malloc(4096)) == NULL) {
　　perror("Cannot allocate stack for child");
　　exit(1);
　　}
　　/* clone process and run in the same memory space */
　　if ((pid = clone((void *)&inc_second, child_stack,              CLONE_VM, &shared_data)) data2++;
　　}
　　}
　　}
　　使用 gcc 编译器，运行清单 6 中的命令不带优化地编译这个示例程序。
　　清单 6. 用于编译清单 5 中例子代码的命令
　　gcc -o cache-miss cache-miss.c
　　现在您可以用 OProfile 分析上述程序中出现的 L2 数据缓存失误。
　　对于这个例子，作者在一台 IBM eServer?? OpenPower?? 710 上执行和分析了这个程序，该机器有两个 POWER5 处理器，并运行 SLES9 Service Pack 1 (SLES9SP1)。将 --list-events 标志传递给 opcontrol，以判断是哪一个事件负责监视 L2 数据缓存失误。对于基于 POWER5 处理器的、运行 SLES9SP1 的系统，由 PM_LSU_LMQ_LHR_MERGE_GP9 事件监视 L2 数据缓存失误。如果您将样本计数设置为 1000，比如在这个例子中，那么 OProfile 将从每 1000 个硬件事件抽取一个样本。如果使用不同的平台，例如基于 POWER4 处理器的服务器，那么这样的事件也会有所不同。
　　使用 清单 7 中的命令分析这个例子代码，如下所示：
　　清单 7. 用来分析清单 5 所示例子中的 L2 数据缓存失误的命令
　　# opcontrol --vmlinux=/boot/vmlinux-2.6.5-7.139-pseries64
　　# opcontrol --reset
　　# opcontrol --setup  event=PM_LSU_LMQ_LHR_MERGE_GP9:1000
　　# opcontrol --start
　　Using 2.6+ OProfile kernel interface.
　　Reading module info.
　　Using log file /var/lib/oprofile/oprofiled.log
　　Daemon started.
　　Profiler running.
　　# ./cache-miss
　　# opcontrol --dump
　　# opcontrol -h
　　Stopping profiling.
　　Killing daemon.
　　# opreport -l ./cache-miss 
　　CPU: ppc64 POWER5, speed 1656.38 MHz (estimated)
　　Counted PM_LSU_LMQ_LHR_MERGE_GP9 events (Dcache miss occurred forthe same real cache line as earlier req, merged into LMQ) with aunit mask of 0x00 (No unit mask) count 1000
　　samples  %        symbol name
　　47897    58.7470  main
　　33634    41.2530  inc_second
　　在分析来自 opreport 的结果时，您可以看到，在函数 main() 和 inc_second() 中存在很多缓存失误。opreport 的 -l 选项将输出符号信息，而实质上输出的应该只是二进制映像名。同样，缓存失误的起因也是两个处理器修改一个共享的数据结构，这个数据结构大小为 8 字节，放在一个 128 字节的缓存行中。
　　消除数据缓存失误的一种方法是填充数据结构，使得它的每一个元素都存储在各自的缓存行中。清单 8 包含一个修改后的结构，其中有 124 字节的填充物。
　　清单 8. 带填充物的数据结构，每个元素放进不同的缓存行中
　　struct shared_data_struct {
　　unsigned int data1;
　　char pad[124];
　　unsigned int data1;
　　图 2 展示了在填充数据结构后，如何使得每个处理器上的每个数据元素都存储在各自的缓存行中。
　　图 2. 共享填充后的数据结构的两个处理器
　　
　　像前面那样重新编译该程序，但是这一次使用修改后的数据结构。然后使用 清单 9 中的命令再次分析结果。
　　清单 9. 填充数据结构后用于 profile L2 数据缓存失误的命令
　　# opcontrol --vmlinux=/boot/vmlinux-2.6.5-7.139-pseries64
　　# opcontrol --reset
　　# opcontrol --setup  event=PM_LSU_LMQ_LHR_MERGE_GP9:1000
　　# opcontrol --start
　　Using 2.6+ OProfile kernel interface.
　　Reading module info.
　　Using log file /var/lib/oprofile/oprofiled.log
　　Daemon started.
　　Profiler running.
　　# ./cache-miss
　　# opcontrol --dump
　　# opcontrol -h
　　Stopping profiling.
　　Killing daemon.
　　# opreport -l ./cache-miss 
　　error: no sample files found: profile specification too strict ?
　　Opreport 表明，由于没有发现抽样数据，所以可能存在错误。然而，随着对共享数据结构的修改，这是可以预期的，因为每个数据元素都在自己的缓存行中，所以不存在 L2 缓存失误。 
　　现在可以考察 L2 缓存失误在处理器周期上的代价。首先，分析使用未填充的原有共享数据结构的代码（清单 4）。您将进行抽样的事件是 CYCLES。使用 清单 10 中的命令针对 CYCLES 事件分析这个例子。
　　清单 10. 用于 profile 清单 5 所示例子中处理器周期数的命令
　　# opcontrol --vmlinux=/boot/vmlinux-2.6.5-7.139-pseries64
　　# opcontrol --reset
　　# opcontrol --setup  event=CYCLES:1000
　　# opcontrol --start
　　Using 2.6+ OProfile kernel interface.
　　Reading module info.
　　Using log file /var/lib/oprofile/oprofiled.log
　　Daemon started.
　　Profiler running.
　　# ./cache-miss
　　# opcontrol --dump
　　# opcontrol -h
　　Stopping profiling.
　　Killing daemon.
　　# opreport -l ./cache-miss 
　　CPU: ppc64 POWER5, speed 1656.38 MHz (estimated)
　　Counted CYCLES events (Processor cycles) with a unit mask of 0x00(No unit mask) count 1000
　　samples  %        symbol name
　　121166   53.3853  inc_second
　　105799   46.6147  main
　　现在，使用 清单 11 中的命令分析使用填充后的数据结构的例子代码（清单 8）。
　　清单 11. 用于分析使用填充后的数据结构的例子中处理器周期数的命令
　　# opcontrol --vmlinux=/boot/vmlinux-2.6.5-7.139-pseries64
　　# opcontrol --reset
　　# opcontrol --setup  event=CYCLES:1000
　　# opcontrol --start
　　Using 2.6+ OProfile kernel interface.
　　Reading module info.
　　Using log file /var/lib/oprofile/oprofiled.log
　　Daemon started.
　　Profiler running.
　　# ./cache-miss
　　# opcontrol --dump
　　# opcontrol -h
　　Stopping profiling.
　　Killing daemon.
　　# opreport -l ./cache-miss 
　　CPU: ppc64 POWER5, speed 1656.38 MHz (estimated)
　　Counted CYCLES events (Processor cycles) with a unit mask of 0x00(No unit mask) count 1000
　　samples  %        symbol name
　　104916   58.3872  inc_second
　　74774    41.6128  main
　　不出所料，随着 L2 缓存失误数量的增加，处理器周期数也有所增加。其主要原因是，与从 L2 缓存取数据相比，从主存获取数据代价昂贵。
　　避免两个处理器之间缓存失误的另一种方法是在相同处理器上运行两个线程。通过使用 Cpu 相似性（affinity），将一个进程绑定到一个特定的处理器，下面的例子演示了这一点。在 Linux 上，sched_setaffinity() 系统调用在一个处理器上运行两个线程。 清单 12 提供了原来的示例程序的另一个变体，其中使用 sched_setaffinity() 调用来执行这一操作。
　　清单 12. 利用 cpu 相似性来避免 L2 缓存失误的示例代码
　　#include 
　　#include 
　　struct shared_data_struct {
　　unsigned int data1;
　　unsigned int data2;
　　};
　　struct shared_data_struct shared_data;
　　static int inc_second(struct shared_data_struct *);
　　int main(){
　　int i, j, pid;
　　cpu_set_t cmask;
　　unsigned long len = sizeof(cmask);
　　pid_t p = 0;
　　void *child_stack;
　　__CPU_ZERO(&cmask);
　　__CPU_SET(0, &cmask);
　　/* allocate memory for other process to execute in */
　　if((child_stack = (void *) malloc(4096)) == NULL) {
　　perror("Cannot allocate stack for child");
　　exit(1);
　　}
　　/* clone process and run in the same memory space */
　　if ((pid = clone((void *)&inc_second, child_stack,CLONE_VM, &shared_data)) data2++;
　　}
　　}
　　}
　　这个例子在同处理器上运行两个线程，共享数据结构存放在一个处理器上的一个 L2 缓存行中。这样应该可以导致零缓存失误。使用前面描述的步骤分析缓存失误，以验证在一个处理器上运行两个进程时，是否不存在 L2 缓存失误。对于数据缓存失误这个问题，第三种解决方法是使用编译器优化，这样可以减少缓存失误的数量。然而，在某些环境下，这不是一个合适的选择，您仍然必须分析代码，并对不良性能做出改正。
　　回页首 
　　结束语
　　分析是开发过程中最困难的任务之一。为了使代码获得最佳性能，好的工具是必不可少的。OProfile 就是这样一种工具，目前它提供了针对 Linux on POWER 的分析功能。对于其他平台上的可以快速移植到 Linux on POWER 的 Linux，还有其他许多性能和调试工具。除了处理器事件的类型有所差别外，在基于 POWER 处理器的 Linux 平台上运行 OProfile 与在其他架构上运行 OProfile 是类似的。所以，如果在其他平台上使用过 OProfile，那么您应该在很短时间内就可以知道如何在 Linux on POWER 上运行 OProfile。
　　回页首 
　　致谢
　　我要感谢 Linda Kinnunen，是她提供了文档模板并对本文进行了审校，我还要感谢 Maynard Johnson 对本文进行了技术上的审校。 
　　参考资料 
　　参与论坛讨论。
　　您可以参阅本文在 developerWorks 全球站点上的 英文原文。
　　在 OProfile 手册的第 2.2 节中，可以找到所有 OProfile 工具 的一个列表。
　　请参阅 OProfile，以获取最新信息。
　　请参阅 SUSE SLES9 Software Developer Kit 网页，以获取关于 SUSE LINUX SDK 9 的更多信息。
　　为了学习关于 Linux on Power 的更多知识，请参阅 IBM developerWorks: Linux on Power Architecture Developer's Corner，可以找到技术文档、教学、下载、产品信息，等等。
　　"Smashing performance with OProfile"（developerWorks，2003 年 10 月）一文提供了关于 OProfile 分析工具的信息。
　　请浏览 GCC 主页，以获得关于 GNU Compiler Collection C 编译器的信息。
　　关于作者
　　John Engel 在 IBM 工作，他是 IBM eServer Solutions Enablement 组织的一名 Linux 技术顾问。他居住在 Rochester, MN。他的主要职责是帮助解决方案开发人员将其应用程序迁移到 Linux on POWER。除了在 IBM 工作以外，他还在进行多方面的 Linux 软件开发。 
　　本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/bekars/archive/2007/03/27/154 2778.aspx