电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛

标题: 评估 Linux on POWER 的性能（4） [打印本页]

作者: look_w 时间: 2017-11-18 22:14 标题: 评估 Linux on POWER 的性能（4）

清单 8. 489.Xalancbmk 基准的 'opreport -' 输出（计数器 PM_DATA_FROM_L2_GRP91 和 PM_DATA_FROM_L3_GRP91）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

CPU: ppc64 POWER7, speed 3550 MHz (estimated)
Counted PM_DATA_FROM_L2_GRP91 events ((Group 91 pm_dsource1) The processor's Data Cache
was reloaded from the local L2 due to a demand load.) with a unit mask of 0x00 (No unit
mask) count 1000
Counted PM_DATA_FROM_L3_GRP91 events ((Group 91 pm_dsource1) The processor's Data Cache
was reloaded from the local L3 due to a demand load.) with a unit mask of 0x00 (No unit
mask) count 1000
samples  %       samples  %       image name    app name    symbol name
767827 25.5750  7581    0.2525  gcc_base.none  gcc_base.none  bitmap_element_allocate
377138 12.5618  8341    0.2778  gcc_base.none  gcc_base.none  bitmap_operation
93334    3.1088  3160    0.1052  gcc_base.none  gcc_base.none  bitmap_bit_p
70278    2.3408  5913    0.1969  libc-2.13.so libc-2.13.so _int_free
56851    1.8936  22874    0.7618  oprofile    oprofile    /oprofile
47570    1.5845  2881    0.0959  gcc_base.none  gcc_base.none  rehash_using_reg
41441    1.3803  8532    0.2841  libc-2.13.so libc-2.13.so _int_malloc

清单 9. 489.Xalancbmk 基准的 'opreport -' 输出（计数器 PM_DATA_FROM_LMEM_GRP91 和 PM_DATA_FROM_RMEM_GRP91）

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Counted PM_DATA_FROM_LMEM_GRP91 events ((Group 91 pm_dsource1) The processor's Data Cache
was reloaded from memory attached to the same module this proccessor is located on.) with
a unit mask of 0x00 (No unit mask) count 1000
Counted PM_DATA_FROM_RMEM_GRP91 events ((Group 91 pm_dsource1) The processor's Data Cache
was reloaded from memory attached to a different module than this proccessor is located
on.) with a unit mask of 0x00 (No unit mask) count 1000
samples  %       samples  %       image name    app name    symbol name
1605    0.3344  0             0  gcc_base.none  gcc_base.none  bitmap_element_allocate
1778    0.3704  0             0  gcc_base.none  gcc_base.none  bitmap_operation
1231    0.2564  0             0  gcc_base.none  gcc_base.none  bitmap_bit_p
205    0.0427  0             0  libc-2.13.so libc-2.13.so _int_free
583    0.1215  327    100.000  oprofile    oprofile    /oprofile
0             0  0             0  gcc_base.none  gcc_base.none  rehash_using_reg
225    0.0469  0             0  libc-2.13.so libc-2.13.so _int_malloc

解释概要文件输出显示，大多数缓存压力来自 L2 访问，几乎不需求从 L3 重载，因为 L2 访问 (PM_DATA_FROM_L2) 的计数器采样值的总数和相对值都比 L3 需求重载 (PM_DATA_FROM_L3) 要高一些。通过进行更全面的分析（通过监视更多计数器），您只能获得进一步的信息，像 L2 访问是否由于缓存未命中而造成 CPU 停滞。从该示例概要文件可以得出的结论是，与缓存访问相比，主内存访问（PM_DATA_FROM_LMEM 事件）相当低，并且没有远程访问（事件 PM_DATA_FROM_RMEM），这意味着没有远程 NUMA 节点内存访问。热点和内存访问模式的分析可以提供优化工作的方向；在本例中，需要进一步进行分析，确定究竟是什么造成 CPU 停顿，因为对于正确识别 CPU 停顿而言，只是简单识别工作负载热点和内存访问模式是远远不够的。
为了制定更好的性能优化策略，需要使用 perf 工具而不是 OProfile 来做进一步的分析，因为需要同时监视很多 POWER7 CMB 计数器，所以中显示了 22 个计数器，以便为性能优化提供更好的策略。许多事件都位于不同的组中，这意味着使用 OProfile 需要多次运行相同的工作负载。若指定的计数器位于多个组中，那么 perf 工具将会复用硬件计数器的监视。虽然这会产生一个准确度稍低的结果，但整体结果往往与预期非常近似，并且具有可以在更短时间内完成分析的优势。
下面的示例使用 perf 分析同一个 SPECcpu2006 483.xalancbmk 组件。要分析这个组件，可以发出的命令：
清单 10. 对生成的 POWER7 CBM 发出的 perf 命令

1
2
3

$ /usr/bin/perf stat -C 0 -e r100f2,r4001a,r100f8,r4001c,r2001a,r200f4,r2004a,r4004a,
r4004e,r4004c,r20016,r40018,r20012,r40016,r40012,r20018,r4000a,r2001c,r1001c,r20014,
r40014,r30004 taskset -c 0 ./Xalan_base.none -v t5.xml xalanc.xsl > power7_cbm.dat

此命令会导致 perf 监视通过 -c 指定的 CPU 上的 -e 参数所定义的原始事件。任务集调用确保该组件将只在 CPU 0 上运行。工作负载 ./Xalan_base.none -v t5.xml xalanc.xsl 可以被另一个应用程序替代为概要文件。完成概要文件的处理之后，perf 命令会输出一个简单的表，显示每个原始事件的总数，以及所花费的总秒数：
清单 11. 489.Xalancbmk 基准的 'perf stat' 输出

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

Performance counter stats for 'taskset -c 0 ./Xalan_base.none -v t5.xml xalanc.xsl':

  366,860,486,404 r100f2                                                    [18.15%]
8,090,500,758 r4001a                                                    [13.65%]
50,655,176,004 r100f8                                                    [ 9.13%]
11,358,043,420 r4001c                                                    [ 9.11%]
10,318,533,758 r2001a                                                    [13.68%]
1,301,183,175,870 r200f4                                                    [18.22%]
2,150,935,303 r2004a                                                    [ 9.10%]
            0 r4004a                                                    [13.65%]
  211,224,577,427 r4004e                                                    [ 4.54%]
  212,033,138,844 r4004c                                                    [ 4.54%]
  264,721,636,705 r20016                                                    [ 9.09%]
22,176,093,590 r40018                                                    [ 9.11%]
  510,728,741,936 r20012                                                    [ 9.10%]
39,823,575,049 r40016                                                    [ 9.07%]
7,219,335,816 r40012                                                    [ 4.54%]
      1,585,358 r20018                                                    [ 9.08%]
  882,639,601,431 r4000a                                                    [ 9.08%]
1,219,039,175 r2001c                                                    [ 9.08%]
      3,107,304 r1001c                                                    [13.62%]
  120,319,547,023 r20014                                                    [ 9.09%]
50,684,413,751 r40014                                                    [13.62%]
  366,940,826,307 r30004                                                    [18.16%]

461.057870036 seconds time elapsed

为了分析针对 POWER7 CBM 的 perf 输出，我们提供了一个 Python 脚本（在中检查 power7_cbm.zip），该脚本由收集到的虚拟和硬件计数器的计数器指标组成。要创建一个报告，可以发出中的命令：
清单 12. POWER7 CBM python 脚本调用

1	$ power7_cbm.py power7_cbm.dat

类似于的输出将被打印出来：
清单 13. 489.Xalancbmk 基准的 'power7_cbm.py' 输出

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

CPI Breakdown Model (Complete)

Metric                      :          Value : Percent
PM_CMPLU_STALL_DIV          : 49802421337.0 :       0.0
PM_CMPLU_STALL_FXU_OTHER    : 67578558649.0 :       5.2
PM_CMPLU_STALL_SCALAR_LONG    :       2011413.0 :       0.0
PM_CMPLU_STALL_SCALAR_OTHER :    7195240404.0 :       0.6
PM_CMPLU_STALL_VECTOR_LONG    :             0.0 :       0.0
PM_CMPLU_STALL_VECTOR_OTHER :    1209603592.0 :       0.1
PM_CMPLU_STALL_ERAT_MISS    : 22193968056.0 :       1.7
PM_CMPLU_STALL_REJECT_OTHER : 18190293594.0 :       1.4
PM_CMPLU_STALL_DCACHE_MISS    : 261865838255.0 :    20.3
PM_CMPLU_STALL_STORE          :    2001544985.0 :       0.2
PM_CMPLU_STALL_LSU_OTHER    : 202313206181.0 :    15.7
PM_CMPLU_STALL_THRD          :       2025705.0 :       0.0
PM_CMPLU_STALL_BRU          : 208356542821.0 :    16.2
PM_CMPLU_STALL_IFU_OTHER    :    2171796336.0 :       0.2
PM_CMPLU_STALL_OTHER          : 30895294057.0 :       2.4
PM_GCT_NOSLOT_IC_MISS       :    9805421042.0 :       0.8
PM_GCT_NOSLOT_BR_MPRED       :    7823508357.0 :       0.6
PM_GCT_NOSLOT_BR_MPRED_IC_MISS : 11059314150.0 :       0.9
PM_GCT_EMPTY_OTHER          : 20292049774.0 :       1.6
PM_1PLUS_PPC_CMPL             : 365158978504.0 :    28.3
OVERHEAD_EXPANSION          :    590057044.0 :       0.0
Total                                           :    96.1

这份报告以误差范围内的统计值为基础，所以最终的比例并不完全准确。即使误差范围较大，CPU 总停滞中仍然只有大约 20% 是由于数据缓存未命中 (PM_CMPLU_STALL_DCACHE_MISS) 引起的。最后的指令完成百分比 (PM_1PLUS_PPC_CMPL) 也有 28% 左右。
未来的优化应尝试通过降低 CPU 停滞和/或 GCT (Global Completion Table) 百分比将该数字最大化。根据这份报告，另一个分析途径是识别发生停滞的代码。要做到这一点，可以使用 perf record 命令。该命令将追踪原始计数器的性能，并利用进程回溯来创建一个映射，从而识别哪个符号生成最多的硬件事件。这类似于 OProfile 的工作方式。在本例中，要跟踪 PM_CMPLU_STALL_DCACHE_MISS 事件，可以发出中的命令：
清单 14. PM_CMPLU_STALL_DCACHE_MISS 事件的 perf record

1	$ /usr/bin/perf record -C 0 -e r20016 taskset -c 0 ./Xalan_base.none -v t5.xml xalanc.xsl

perf 命令将利用结果创建一个数据文件（通常是 "perf.dat"）。使用 perf record 命令能够以交互方式读取它，如所示：

欢迎光临电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/)