实战：从寄存器配置到性能瓶颈定位)
1. 项目概述与核心价值性能监控对于任何一个在底层系统、嵌入式开发或者高性能计算领域摸爬滚打的工程师来说都像是一把打开处理器黑盒的钥匙。我们写的代码最终如何在CPU的流水线、缓存、执行单元里“奔跑”性能监控设施能给出最直观、最底层的答案。它不是那种高高在上的理论而是实打实的、能帮你定位到具体哪个循环因为缓存未命中而卡顿哪个函数因为分支预测失败而拖慢整个流程的利器。今天要聊的是飞思卡尔Freescale现属NXPe6500内核的性能监控单元Performance Monitor Unit, PMU。e6500作为Power Architecture e6500系列的高性能多线程内核广泛应用在网络处理器、通信基础设施等对性能极其敏感的领域。理解它的PMU意味着你能从硬件层面透视这个复杂内核的“心跳”和“脉搏”。很多人可能觉得看手册就行了但手册是死的是字典它告诉你每个寄存器位是干嘛的却很少告诉你为什么要这么配置以及在实际操作中会遇到哪些“坑”。我在这行干了十几年调试过无数基于e6500及其前代e500核心的系统深知从寄存器配置到得出有意义的性能数据中间隔着不少实践经验和技巧。这篇文章我就结合手册和实际调试经验带你彻底拆解e6500的性能监控。我们会从最基础的寄存器模型和事件选择讲起一步步深入到计数器配置、中断机制最后通过几个典型的性能分析场景手把手教你如何配置、采集并解读数据。目标是让你读完就能上手在下次遇到性能瓶颈时能自信地打开性能监控工具而不是对着满屏的十六进制数发呆。2. e6500性能监控设施架构解析要玩转性能监控首先得搞清楚它提供了哪些“武器”。e6500的PMU架构设计得相当完整它不是一个简单的计数器集合而是一套包含控制、计数、触发和快照的完整系统。2.1 核心寄存器组控制与数据的枢纽e6500的性能监控功能主要通过一组特殊的性能监控寄存器Performance Monitor Registers, PMRs来访问和控制而不是使用更常见的特殊目的寄存器SPRs。这一点需要特别注意意味着操作它们的指令是mfpmr从PMR移动和mtpmr移动到PMR。整个PMU的核心可以概括为以下几类寄存器性能监控计数器PMC0-PMC5这是六个32位的计数器用于实际累加我们关心的事件发生次数。它们是只读的其值随着选定事件的发生而递增。当计数器从最大值0xFFFFFFFF溢出回到0时会置位一个溢出标志。性能监控全局控制寄存器PMGC0这是PMU的“总开关”。它有几个关键位PMIE (Performance Monitor Interrupt Enable)全局性能监控中断使能位。只有此位置1某个PMC的溢出事件才有可能触发中断。FCECE (Freeze Counters on Enabled Condition or Event)这个位非常有用。当置1时一旦某个使能的条件或事件比如计数器溢出且使能发生所有性能监控计数器都会立即停止计数冻结。这保证了在中断服务程序读取计数器值时数值是事件发生瞬间的精确快照不会因为继续计数而被污染。对于需要精确测量特定代码段事件的场景这是必须的配置。FAC (Freeze All Counters)手动冻结所有计数器。当你想暂停所有计数以便安全读取时可以设置此位。TBSEL (Time Base Select)选择哪个时间基寄存器TBL的位变化作为一个可监控的事件对应事件Com:90。性能监控本地控制寄存器PMLCa0-PMLCa5, PMLCb0-PMLCb5每个PMC计数器都对应一对控制寄存器PMLCa和PMLCb。它们才是真正定义“数什么”和“怎么数”的核心。PMLCa寄存器主要包含事件选择字段EVENT、计数器使能CE用于控制该计数器溢出时是否作为中断条件、以及处理器上下文过滤字段FCS,FCU,FCM1,FCM0,FCGS0,FCGS1。上下文过滤功能允许你只统计在特定处理器状态如用户模式、监管模式、标记进程下发生的事件这对于多任务环境下的性能剖析至关重要。PMLCb寄存器主要包含计数器阈值比较相关的控制位在某些测量场景下使用。实操心得寄存器访问的坑刚开始用mfpmr/mtpmr时很容易和mfspr/mtspr搞混。务必记住e6500的性能监控寄存器是PMR地址空间的一部分。在编写内核模块或监控代码时一定要使用正确的指令。此外这些寄存器通常需要在监管者超级用户模式下才能进行写操作用户模式通常只有读权限通过UPMGC0,UPMLCaX,UPMLCbX等用户可读别名寄存器。在设计性能剖析工具时需要考虑权限问题。2.2 事件体系微观世界的探针e6500 PMU最强大的地方在于其极其丰富和细致的事件列表。手册中的Table 9-61就像一份详尽的“可观测事件菜单”。这些事件大致可以分为几大类通用事件如处理器周期Ref:1、完成指令数Ref:2、完成微操作数Com:3等。这是计算CPI每指令周期数、IPC每周期指令数等宏观指标的基础。指令类型事件细分到不同执行单元如分支指令完成Com:8、加载/存储微操作完成Com:9, Com:10、SFX/CFX/FPU/AltiVec指令完成等。这能帮你分析程序的计算特征。流水线停滞事件这是性能分析的黄金数据。例如“解码停滞周期”Com:18、“LSU发射停滞周期”Com:110、“指令缓冲区空周期”Com:122等。这些事件直接告诉你流水线在哪里“堵车”了。缓存与内存子系统事件包括L1数据/指令缓存命中/未命中Com:221, Com:254、L2缓存事件Com:456-Com:472、TLB未命中Com:48, Com:256等。这是定位“内存墙”问题的关键。分支预测事件如分支误预测Com:15、BTB命中/未命中Com:71, Com:72等。对于存在大量条件跳转的代码优化分支预测能带来巨大收益。资源冲突与仲裁事件如存储队列STQ冲突Com:243-250、线程间资源争用Com:100, Com:253等。这在多线程环境下分析性能干扰时非常有用。每个事件都有一个编号如Com:221和一个“Spec/Nonspec”属性。“Spec”表示该事件会计入推测执行可能被后续冲刷掉的操作而“Nonspec”只计入最终被架构提交的操作。在分析程序实际性能时通常更关注“Nonspec”事件因为它们反映了程序真实的执行路径。而“Spec”事件对于分析处理器前端预测效率和流水线气泡更有价值。2.3 快照与捕获功能定格瞬间状态除了持续计数e6500 PMU还提供了一个强大的“快照”功能。你可以配置一个触发信号例如某个数据地址匹配DAC、某个指令地址匹配IAC或者外部EVTI信号当触发条件满足时硬件会自动将所有六个PMC的当前值以及当前的程序计数器PC捕获到一组专用的捕获寄存器中。这个功能对于实时调试和性能分析是无价之宝。想象一下当你的程序在某个神秘地址发生性能骤降时你可以设置一个基于性能计数器溢出的触发条件例如L2未命中超过阈值一旦触发瞬间冻结所有计数器并记录PC。你就能精确知道是执行到哪条指令时出现了异常高的缓存未命中而不是事后从平均数据中去猜测。3. 性能监控计数器配置实战知道了有什么下一步就是怎么用。配置一个性能计数器远不止是往EVENT字段写个数字那么简单它是一系列权衡和精确控制的结果。3.1 事件选择与上下文过滤假设我们想监控用户模式下L1数据缓存未命中Com:221的次数。配置PMC0的步骤如下选择事件查表9-61事件Com:221的编码需要写入PMLCa0[EVENT]字段。假设其编码为0xDD具体值需查手册此处为示例。设置上下文过滤我们只想统计用户模式下的未命中。根据手册Table 9-59要监控“User”状态需要设置PMLCa0[FCS]1,PMLCa0[FCU]0,PMLCa0[FCM1]0,PMLCa0[FCM0]0。FCGS0和FCGS1用于客户/监管者状态过滤在非虚拟化环境中通常设为0。使能计数器与溢出中断将PMLCa0[CE]置1使能该计数器的溢出作为中断条件。同时确保PMGC0[PMIE]也置1以全局使能性能监控中断。初始化计数器通过mtpmr指令将PMC0清零。对应的伪代码示例如下// 假设有对应的寄存器地址定义 #define PMLCa0_EVENT_OFFSET 0x00 #define PMLCa0_CTRL_OFFSET 0x04 // 假设控制位在另一个偏移 void configure_pmc0_for_user_dcache_miss(void) { // 1. 设置事件编号为 L1 D-Cache Miss (示例编码) uint32_t pmlca0_val (0xDD EVENT_SHIFT); // 2. 设置上下文过滤为仅用户模式: FCS1, FCU0, FCM10, FCM00 pmlca0_val | (1 FCS_BIT_POS); pmlca0_val ~(1 FCU_BIT_POS); pmlca0_val ~(1 FCM1_BIT_POS); pmlca0_val ~(1 FCM0_BIT_POS); // 3. 使能计数器溢出中断条件 pmlca0_val | (1 CE_BIT_POS); // 写入PMLCa0寄存器 mtpmr(PMLCa0_ADDR, pmlca0_val); // 4. 清零PMC0计数器 mtpmr(PMC0_ADDR, 0); // 5. 可选使能全局性能监控中断 uint32_t pmgc0_val mfpmr(PMGC0_ADDR); pmgc0_val | (1 PMIE_BIT_POS); // 如果希望溢出时冻结所有计数器以获取精确值同时设置FCECE位 pmgc0_val | (1 FCECE_BIT_POS); mtpmr(PMGC0_ADDR, pmgc0_val); }3.2 计数器链式连接扩展计数范围每个PMC只有32位对于高频事件如处理器周期可能很快溢出。为了测量长时间运行的事件e6500支持计数器链式连接。例如可以将PMC0的溢出事件作为PMC1的计数事件事件Com:82。这样每当PMC0溢出PMC1就加1。PMC1就变成了PMC0的高32位共同组成了一个64位计数器。配置链式计数器时需要配置PMC0计数基础事件如处理器周期并使其能溢出CE1。配置PMC1将其事件选择设置为“PMC0溢出”Com:82。读取64位值时需要小心并发问题。如果计数器在运行未冻结直接先后读取PMC1和PMC0可能会因为中间发生溢出而导致读数不一致。手册提供了一个标准的读序列见9.12.5.1节通过重复读取高位并比较来确保数据一致性。更简单的做法是在读取前通过设置PMGC0[FCECE]或PMGC0[FAC]来冻结所有计数器。3.3 利用快照功能进行触发式采样快照功能的配置相对独立主要通过性能监控快照配置寄存器PMSCR来完成。你可以将快照触发源配置为32个监视点Watchpoint的任意组合逻辑。监视点来源包括内部可重载计数器外部事件输入EVTI0/1通常来自SoC的事件处理单元EPU指令地址匹配IAC数据地址匹配DAC其他监视点源一个典型应用是设置一个IAC监视点指向你怀疑有性能问题的函数入口。同时在PMSCR中配置当该IAC匹配时触发快照。然后你提前配置好PMC来计数相关事件如缓存未命中、流水线停滞。当程序执行到该函数时触发快照所有PMC值和PC被捕获。你可以通过内存映射接口读取这些捕获寄存器从而得到函数入口时刻的性能计数器基线值。结合函数执行一段时间后的计数器值就能精确分析该函数内部的性能行为。注意事项快照与中断的区分快照触发和性能监控中断是两套独立的机制。快照是“静默”捕获不会产生异常或中断适合非侵入式采样。而性能监控中断是基于计数器溢出的会打断程序流适合用于设置性能阈值告警或周期性采样。两者可以结合使用例如用计数器溢出触发中断在中断服务程序中进行更复杂的处理或记录。4. 性能监控中断机制深度剖析中断机制是PMU从被动计数变为主动响应的关键。e6500的性能监控中断遵循Power ISA架构定义的中断模型使用固定的中断向量偏移IVOR35。4.1 中断触发条件一个性能监控中断的发生需要满足一个与逻辑链事件发生某个PMCn发生溢出即PMCn[OV]位被硬件置1。本地使能该PMCn的溢出中断条件被使能PMLCan[CE] 1。全局使能性能监控全局中断使能PMGC0[PMIE] 1。中断使能处理器当前状态下的中断被使能。这取决于中断是定向到客户状态还是监管者状态由EPCR[PMGS]位控制并且需要MSR[EE]外部中断使能和MSR[GS]客户状态等位的配合。只有这四个条件同时满足处理器才会真正跳转到IVOR35指向的中断处理程序。4.2 中断服务程序ISR设计要点编写性能监控中断服务程序时有几个关键点必须处理现场保存与恢复必须严格按照Power ABI保存和恢复所有可能被破坏的寄存器。中断原因判定进入ISR后你需要检查是哪个PMC触发了中断。这需要读取所有PMCn[OV]标志位或PMLCan中的相关状态位。通常你会遍历PMC0-PMC5检查溢出标志。计数器处理读取计数器值在冻结计数器通过FCECE或FAC后安全地读取PMC值。如果你需要计算事件发生的绝对次数需要结合溢出次数可能需要软件维护一个溢出次数的高位计数器和当前PMC值。清除溢出标志通过向PMCn[OV]位写1来清除溢出标志。重要不清除标志可能导致中断无法再次触发或产生虚假中断。重启计数器根据你的测量策略决定是清零计数器重新开始还是恢复其原有值继续计数。如果测量是周期性的通常选择清零。退出中断执行rfi指令返回被中断的程序。下面是一个极度简化的伪代码示例展示了ISR的核心逻辑performance_monitor_isr: // 1. 保存寄存器 (根据ABI) stwu r1, -STACK_FRAME_SIZE(r1) mflr r0 stw r0, STACK_FRAME_SIZE4(r1) // ... 保存其他 volatile 寄存器 // 2. 冻结计数器以确保读数稳定如果之前没设置FCECE mfpmr r3, PMGC0_ADDR oris r3, r3, FAC_BIT_MASK // 设置FAC位 mtpmr PMGC0_ADDR, r3 isync // 3. 判定中断源并处理 li r4, 0 // 循环索引对应PMC0 check_pmc_loop: // 获取PMLCa寄存器值检查CE和溢出状态这里简化实际需查手册位域 // 假设通过某个偏移能读到包含OV标志的状态 mfpmr r5, PMLCa0_STATUS_ADDR(r4) andi. r6, r5, CE_AND_OV_MASK cmpwi r6, CE_AND_OV_MASK bne next_pmc // 这个PMC触发了中断 // 3.1 读取PMC值 mfpmr r7, PMC0_ADDR(r4) // 将r7的值存储到你的数据记录区并累加软件维护的溢出高位计数 // 3.2 清除PMC溢出标志 (写1清0) ori r5, r5, OV_CLEAR_MASK mtpmr PMLCa0_STATUS_ADDR(r4), r5 // 3.3 可选重置PMC计数器为0 li r8, 0 mtpmr PMC0_ADDR(r4), r8 next_pmc: addi r4, r4, 1 cmpwi r4, 6 blt check_pmc_loop // 4. 解除计数器冻结 mfpmr r3, PMGC0_ADDR rlwinm r3, r3, 0, ~FAC_BIT_MASK // 清除FAC位 mtpmr PMGC0_ADDR, r3 isync // 5. 恢复寄存器并返回 lwz r0, STACK_FRAME_SIZE4(r1) mtlr r0 addi r1, r1, STACK_FRAME_SIZE rfi4.3 中断使能状态与计数器冻结的微妙关系手册里强调了一个容易忽略但至关重要的细节即使PMC溢出且PMGC0[PMIE]1如果处理器当前的中断使能条件不满足例如MSR[EE]0中断也不会被“获取”taken。这里有一个关键场景假设PMGC0[FCECE]0溢出时不冻结计数器中断被暂时屏蔽。此时PMC溢出但由于中断未使能硬件不会处理。PMC会从0xFFFFFFFF翻转到0x00000000继续计数。当中断后来被使能时之前那次溢出事件不会补发中断你可能会因此丢失一次溢出事件。避坑指南中断与冻结的配置策略因此在需要精确统计溢出次数的应用中强烈建议设置PMGC0[FCECE]1。这样一旦发生符合条件的溢出事件所有计数器立即冻结中断处于“待决”状态。即使当前中断被屏蔽计数器值也定格在了溢出时刻。当中断使能后处理器会立即响应这个待决的中断你在ISR中读取到的计数器值就是溢出时的精确值0xFFFFFFFF或接近然后你可以安全地处理溢出、清零、重启计数。这避免了在中断延迟期间计数器翻转导致的数据错误。5. 典型性能分析场景与配置示例理论说再多不如看几个实际怎么用的例子。下面我结合常见性能问题给出具体的PMU配置思路。5.1 场景一定位CPU流水线前端瓶颈症状程序IPC每周期指令数很低怀疑指令获取或解码是瓶颈。分析思路关注取指Fetch和解码Decode阶段的停滞事件。PMU配置方案PMC0: 事件Com:122(Cycles IB empty) – 统计指令缓冲区为空的周期数。这直接反映了取指单元是否“喂不饱”后端。PMC1: 事件Com:123(Cycles IB full or close to full) – 统计指令缓冲区满的周期数。这反映了后端消费指令的速度是否跟不上取指速度或者取指是否被阻塞如I-Cache未命中。PMC2: 事件Com:18(Cycles decode stalled) – 统计解码器停滞的周期数。即使指令缓冲区有指令解码器也可能因资源冲突等原因停滞。PMC3: 事件Ref:1(Processor cycles) – 作为总周期数基准。计算与解读IB空占比 PMC0 / PMC3。如果占比很高说明程序流或I-Cache命中率导致取指经常断流。IB满占比 PMC1 / PMC3。高占比通常意味着后端执行单元或流水线存在瓶颈消费指令慢。解码停滞占比 PMC2 / PMC3。高占比需要结合具体指令序列分析可能是遇到了复杂的指令组合或资源限制。5.2 场景二分析缓存效率与“内存墙”症状数据处理密集型程序性能未达预期怀疑缓存未命中率高。分析思路分层统计缓存访问和未命中情况。PMU配置方案PMC0: 事件Com:221(Data L1 cache misses) – L1数据缓存未命中次数。PMC1: 事件Com:9(Load micro-ops completed) Com:10(Store micro-ops completed) – 需要两个计数器分别统计或通过两次运行获取。近似代表总的L1数据缓存访问次数。PMC2: 事件Com:456(L2 hits) – L2缓存命中次数需注意此事件是核心共享L2的事件。PMC3: 事件Com:457(L2 misses) – L2缓存未命中次数。PMC4: 事件Com:26(Total translated) – 近似代表LSU加载存储单元的总操作数作为分母之一。计算与解读L1 D-Cache Miss Rate PMC0 / (PMC1_load PMC1_store)。如果5%就需要审视数据访问模式考虑数据布局、结构体大小、循环步长。L2 Miss Rate PMC3 / (PMC2 PMC3)。高L2未命中率会直接导致访问片外内存延迟急剧增加。结合Com:48(DTLB miss times)可以判断是否还存在页表遍历的开销。5.3 场景三剖析多线程资源争用症状双线程程序性能达不到单线程的2倍甚至更差。分析思路e6500是同时多线程SMT处理器两个硬件线程共享大部分核心资源。需要查看共享资源的冲突事件。PMU配置方案需为每个线程单独配置利用上下文过滤或线程特定的计数器事件线程0配置:PMC0:Com:100(Number of times LSU thread priority switched) – LSU线程优先级切换次数反映资源仲裁。PMC1:Com:253(Inter-thread doubleword bank collisions) – 线程间双字存储体冲突次数。L1数据缓存通常分bank同时访问同一bank会导致冲突停顿。PMC2:Com:101(Cycles both threads had FPU requests and one was denied) – FPU资源争用导致的拒绝周期数。线程1配置配置相同的事件但通过软件在运行时分别对两个线程的PMU进行配置和读取。计算与解读高频率的Com:100和Com:253表明两个线程的数据访问模式存在严重的地址交错冲突可能需要调整数据布局或线程任务分配。Com:101等事件计数高表明浮点计算密集型线程在争夺执行单元可能需要考虑将浮点计算任务更均匀地分开或者检查是否一个线程的浮点操作阻塞了另一个。5.4 场景四使用链式计数器进行长时间采样任务需要统计一个运行时间很长的任务例如处理一个大数据包的总处理器周期数远超32位计数器的范围。PMU配置方案PMC0: 配置为计数Ref:1(Processor cycles)并使能溢出中断CE1。PMC1: 配置为计数Com:82(PMC0 overflow)。这样PMC1就记录了PMC0的溢出次数。PMGC0: 设置FCECE1确保PMC0溢出触发中断时所有计数器冻结保证读取一致性。中断服务程序在ISR中读取冻结的PMC0和PMC1。总周期数 (PMC1 32) PMC0。然后清零PMC0和PMC1并重启它们清除FAC或FCECE状态继续测量。结果你得到了一个64位的周期计数器可以测量任意长的任务。实操心得性能监控的开销开启性能监控尤其是频繁的中断本身会引入开销影响被测量程序的真实行为即“观察者效应”。对于需要精确测量的场景有几点建议尽量使用快照而非中断对于采样分析快照的侵入性更低。增大计数器阈值通过链式计数器或设置较高的溢出阈值减少中断频率。测量校准可以运行一个空循环或已知计算量的基准程序先测量出PMU监控本身带来的周期开销在分析最终数据时将其扣除。关注相对值而非绝对值在优化前后使用相同的监控配置进行对比相对性能提升的百分比通常比绝对周期数更有意义。6. 常见问题与调试技巧实录在实际使用e6500 PMU的过程中我踩过不少坑也总结了一些调试技巧。6.1 问题一配置了事件但计数器不递增可能原因1上下文过滤不匹配。这是最常见的原因。你配置了只监控“用户模式”但你的测试代码一直在监管模式下运行。检查MSR[PR]和MSR[PMM]位的实际状态并与PMLCa中的FCS/FCU/FCM设置对比。一个简单的调试方法是先将所有过滤位FCS, FCU, FCM1, FCM0清零这表示“无条件计数”。如果此时计数器开始递增问题就出在上下文过滤上。可能原因2事件选择编码错误。Table 9-61中的事件编号如Com:221不等于直接写入EVENT字段的值。必须查阅寄存器位域定义找到正确的编码值。手册通常会有一个单独的表格或章节说明EVENT字段的编码映射。可能原因3处理器处于低功耗状态。手册明确指出在PH15, PH20, PH30, PW20这些电源管理活动状态下性能监控活动是暂停的。确保你的测量阶段处理器处于活跃状态。可能原因4全局或本地冻结。检查PMGC0[FAC]是否被意外置位或者PMLCan[FC]是否被置位。这些位会强制禁用对应计数器的计数。6.2 问题二性能监控中断无法触发检查中断使能链按照4.1节的逻辑链逐一排查。PMC溢出标志OV是否置1读取PMC或PMLCa状态PMLCan[CE]是否置1PMGC0[PMIE]是否置1处理器当前中断是否使能检查MSR[EE]以及EPCR[PMGS]和MSR[GS]的组合是否符合你的预期是监管态中断还是客户态中断。检查IVOR35设置确保中断向量表IVOR35指向了你正确的中断处理程序。使用快照功能辅助调试如果怀疑中断逻辑可以先用快照功能。配置一个基于PMC溢出的快照触发通过PMSCR并捕获PC。如果快照能触发并捕获到PC说明PMC溢出事件确实发生了问题可能出在中断使能或向量表上。如果快照都不触发那肯定是前三个条件没满足。6.3 问题三读取的计数器值看起来不合理过大、过小或跳变线程干扰在SMT双线程环境下默认情况下性能监控事件是两个线程合计的。如果你只想监控其中一个线程必须使用上下文过滤功能结合MSR中的线程标识位如果支持或通过软件控制只在目标线程运行时开启计数。计数器溢出与回绕32位计数器在高频事件下可能几秒就溢出。如果你在溢出后读取看到的是一个很小的值因为回绕到了0附近。始终要结合溢出中断或链式计数器来扩展范围。推测执行计数确认你选择的事件是“Spec”还是“Nonspec”。如果你选的是“Spec”事件如很多流水线停滞事件它的计数会包含那些被取指、解码但最终被冲刷掉的指令这个值可能远大于实际提交的指令数这是正常的。读取顺序问题在计数器未冻结时读取链式计数器必须使用手册推荐的“读-读-比较”循环来确保读取一致性。否则高低位可能来自不同的时间点。6.4 性能监控编程的实用技巧封装寄存器操作在C代码中将mfpmr/mtpmr封装成易于使用的函数或宏并做好错误检查。保存与恢复PMU状态如果你的代码需要临时使用PMU或者在一个任务切换频繁的系统中在进入你的性能剖析代码前务必保存所有PMU寄存器的状态并在退出时恢复。否则会干扰操作系统或其他任务可能使用的性能监控。利用用户可读寄存器UPMLCaX和UPMLCbX寄存器允许用户态程序在适当权限下读取配置。这可以用于实现用户态的性能剖析库无需每次采样都陷入内核。从宏观到微观开始性能分析时先用通用事件周期、指令数计算IPC定位大致瓶颈范围前端、后端、内存。然后再用更具体的事件缓存未命中、资源冲突深入挖掘根本原因。结合软件性能工具硬件PMU提供的是底层数据。需要将其与软件层面的信息如符号表、调用栈、源代码行号关联起来。这通常需要操作系统内核的支持如Linux的perf子系统或者自己开发工具来在中断/快照时捕获PC并解析为函数名。e6500的性能监控设施是一套非常强大的底层分析工具。它提供的细致程度足以让你对处理器的微观行为进行“X光”级别的检查。掌握它需要反复实践从简单的计数器开始逐步尝试更复杂的中断、链式和快照功能。每一次成功的性能问题定位都会让你对计算机体系结构的理解加深一层。记住所有的优化都必须建立在测量之上而PMU就是那把最精确的尺子。
