首页 > *nix技术, X86芯片, 硬件设备 > Intel 性能监视器之二

Intel 性能监视器之二

2013年4月21日 发表评论 阅读评论 13,756 次浏览

全文来自Intel开发者手册:Intel? 64 and IA-32 Architectures Software Developer’s Manual Volume 3B System Programming Guide.pdf

注意:下文中已经指出手册中的对应页面和章节,请对照手册原文看,任何个人理解错误,请包涵。

六,以下内容来自(P290):30.2.3 Pre-defined Architectural Performance Events
表格30-1列出了预先定义好的架构兼容事件

Table 30-1. UMask and Event Select Encodings for Pre-Defined Architectural Performance Events
Bit Position CPUID.AH.EBX Event Name UMask Event Select
0 UnHalted Core Cycles 00H 3CH
1 Instruction Retired 00H C0H
2 UnHalted Reference Cycles 01H 3CH
3 LLC Reference 4FH 2EH
4 LLC Misses 41H 2EH
5 Branch Instruction Retired 00H C4H
6 Branch Misses Retired 00H C5H

有些处理器可能并不全部支持上表列出的所有预定义架构兼容事件,这可以通过检测CPUID.0AH:EBX对应的bit位来做判断,只有bit位为零,才表示支持对应的事件。

几个事件的注意点:
0,UnHalted Core Cycles — Event select 3CH, Umask 00H
简明:统计处于非停机(UnHalted)状态的时钟周期数。什么是UnHalted状态?比如执行hlt指令时,cpu就处于Halted状态。
只有当指定处理器上的时钟信号处于运行状态时,该事件计数器才统计该处理器的核心时钟周期数。因此在如下几种情况时,计数器不会增长:

— an ACPI C-state other than C0 for normal operation
— HLT
— STPCLK# pin asserted
— being throttled by TM1
— during the frequency switching phase of a performance state transition (see Chapter 14, “Power and Thermal Management”)

另外,在性能状态发生改变,比如由性能最佳变成节能状态,那么对应的核心时钟频率会发生变化,从而该性能计数器的统计频率也会随之发生变化。

1,Instructions Retired — Event select C0H, Umask 00H
简明:统计已执行完的指令数。Retired表示引退,意译也就是消耗或已执行完。
该事件计数器统计已执行的指令数。如果一条指令由多条微指令组成,那么该事件计数器仅对其最后一条微指令进行统计。如果一条指令以rep为前缀(即意味着指令将执行多次),那么也将作为整体而只被统计一次。如果在多操作指令的最后一条微指令执行完之前出现错误,那么将不会被统计。处于VM-exit条件下时,该事件不会增长。在硬中断,traps陷进以及中断处理函数内时,该计数器都将继续统计。

2,UnHalted Reference Cycles — Event select 3CH, Umask 01H
简明:统计处于非停机(UnHalted)状态的参考时钟周期数。
只有当指定处理器上的时钟信号处于运行状态时,该事件计数器才统计该处理器的参考时钟周期数。这和UnHalted Core Cycles类似,但不同的是,该性能计数器的统计频率不会因核心时钟频率受性能状态发生改变影响而发生变化。

七,下面是与NMI中断相关的部分,属于个人总结
1,Linux内核有一个nmi_watchdog机制,可以用来检测死锁。
这可以参考内核文档:2.6.30.8\Documentation\nmi_watchdog.txt

2,第1点是旧的nmi_watchdog机制,自2.6.37.x开始,有了新的nmi_watchdog机制。
a) 关于new nmi_watchdog介绍,在这里:new nmi_watchdog using perf events

b) new nmi_watchdog出现在2.6.37.2之后(在内核更新log里搜索关键字“new nmi_watchdog”):
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/?id=5f2b0ba4d94b3ac23cbc4b7f675d98eb677a760a&qt=grep&q=new+nmi_watchdog

Age Commit message (Expand) Author Files Lines
2010-11-18 x86, nmi_watchdog: Remove the old nmi_watchdog Don Zickus 7 -608/+5
2010-05-12 lockup_detector: Combine nmi_watchdog and softlockup detector Don Zickus 12 -29/+650
2010-02-08 nmi_watchdog: Config option to enable new nmi_watchdog Don Zickus 5 -1/+26
2010-02-08 x86: Move notify_die from nmi.c to traps.c Don Zickus 2 -7/+5

c) 在2.6.37.x内,新旧两套nmi机制同时存在,但old nmi_watchdog机制在2.6.38后被移除:
x86, nmi_watchdog: Remove the old nmi_watchdog

3,新的nmi_watchdog机制,其nmi中断源不再可以设置为IO-APIC(即nmi_watchdog=1),而只能是local APIC(即nmi_watchdog=2)。
具体而言是通过:性能计数器溢出(Hardware counter overflow interrupt) –> local APIC(合适配置进行转换) –> NMI
在Intel开发者手册3A第460页(10.1 LOCAL AND I/O APIC OVERVIEW)有对应的说明:

? Performance monitoring counter interrupts — P6 family, Pentium 4, and
Intel Xeon processors provide the ability to send an interrupt to its associated
processor when a performance-monitoring counter overflows (see Section
30.8.5.8, “Generating an Interrupt on Overflow”).

以及Intel开发者手册3B第342页(30.8.5.8 Generating an Interrupt on Overflow)的说明:

(Here, the performance counter entry in the local vector table [LVT] is set
up to deliver the interrupt generated by the PMI to the processor.)

另外可以参考文档:PerfEvent与Intel PMU介绍(林铭 Intel开源技术中心)

4,新的nmi_watchdog机制的使用:
新的watchdog只需打开内核选项接口(参考文档:lockup-watchdogs.txt,也就是原来的nmi_watchdog.txt):
Kernel hacking —>
[*] Detect Hard and Soft Lockups
[*] Panic (Reboot) On Hard Lockups
[*] Panic (Reboot) On Soft Lockups

新机制处理了nmi的嵌套问题:http://lwn.net/Articles/484932/
对应的源文件:http://lxr.linux.no/#linux+v3.6.11/arch/x86/kernel/entry_64.S#L1615

5,新的nmi_watchdog机制的关键性配置语句为:

apic_write(APIC_LVTPC, APIC_DM_NMI);

其使用的具体性能计数器与当前机器CPU型号有关,在最一般情况下,使用的是:

#define MSR_ARCH_PERFMON_PERFCTR0		0xc1
#define MSR_ARCH_PERFMON_EVENTSEL0		0x186

事件为:

#define ARCH_PERFMON_UNHALTED_CORE_CYCLES_SEL	(0x3c)
#define ARCH_PERFMON_UNHALTED_CORE_CYCLES_UMASK		(0x00 << 8)

可以看到这是架构兼容事件UnHalted Core Cycles。由于统计的是非停机时钟周期,所以如果系统比较空闲,那么通过“cat /proc/interrupts | grep NMI”看到的nmi中断增长比较缓慢。这是因为当系统空闲时,idle进程默认执行的是mwait_idle()函数,其核心指令mwait导致CPU处于停机状态,所以流逝的时钟周期没有统计到计数器内,进而原本要溢出的计数器没有溢出,nmi中断也就没有触发。

6,如何让新nmi_watchdog机制下的nmi中断持续触发?
第5点中提到,如果系统比较空闲,那么系统里的nmi中断数会很少。可以有不少方法提升nmi中断频率:
a) 让系统不要处于空闲状态,比如弄个死循环程序一直跑起。(这个仅用于验证的确是因为CPU空闲导致的,囧)
b) 修改内核参数,加上“idle=poll”(可以参考2.6.30.8\Documentation\kernel-parameters.txt),这样让系统的idle进程执行cpu_relax()函数,而该函数的核心是nop指令,因此CPU并不会处于停机状态。(这会导致无法节能,浪费国家电力,囧)
b) 有个名为“CPU_CLK_UNHALTED.TOTAL_CYCLES”的统计事件:
http://software.intel.com/sites/products/documentation/doclib/stdxe/2013/amplifierxe/win/ug_docs/reference/pmm/events/cpu_clk_unhalted.total_cycles.html
Performance Analysis Guide for Intel? Core? i7 Processor and Intel? Xeon? 5500 processors.pdf
这只是CPU_CLK_UNHALTED的变体,pdf里的解释如下:

Total cycles can be directly measured with CPU_CLK_UNHALTED.TOTAL_CYCLES.
This event is derived from CPU_CLK_UNHALTED.THREAD by setting the cmask = 2
and inv = 1, creating a condition that is always true. The difference between these two is
the halted cycles. These occur when the OS runs the null process.

即创造一个恒真的环境,让计数器的每次统计总是自增。不过根据Intel? VTune手册以及实测来看,这个事件应该仅被某些处理器支持,上面pdf文档就是针对的i7和至强5500系列cpu。libpfm-4.2.0库仅针对Nehalem、Westmere、Sandybridge提供有TOTAL_CYCLES。该事件的具体设置为:
UMask = 0x00;
CMask = 2;
Inv = 1
即:

#define ARCH_PERFMON_UNHALTED_CORE_CYCLES_UMASK	(0x0 | (1 << 23) | (0x2 << 24))

转载请保留地址:http://www.lenky.info/archives/2013/04/2258http://lenky.info/?p=2258


备注:如无特殊说明,文章内容均出自Lenky个人的真实理解而并非存心妄自揣测来故意愚人耳目。由于个人水平有限,虽力求内容正确无误,但仍然难免出错,请勿见怪,如果可以则请留言告之,并欢迎来讨论。另外值得说明的是,Lenky的部分文章以及部分内容参考借鉴了网络上各位网友的热心分享,特别是一些带有完全参考的文章,其后附带的链接内容也许更直接、更丰富,而我只是做了一下归纳&转述,在此也一并表示感谢。关于本站的所有技术文章,欢迎转载,但请遵从CC创作共享协议,而一些私人性质较强的心情随笔,建议不要转载。

法律:根据最新颁布的《信息网络传播权保护条例》,如果您认为本文章的任何内容侵犯了您的权利,请以Email或书面等方式告知,本站将及时删除相关内容或链接。

  1. 本文目前尚无任何评论.
  1. 本文目前尚无任何 trackbacks 和 pingbacks.