4. 调试接口总览

PMU（Performance Monitoring Unit）用得好不好，关键看中断。我见过不少工程师，计数器配置得头头是道，但一遇到中断处理就翻车。说白了，PMU中断不是普通的外设中断，它跟CPU流水线、多核同步、甚至调试状态都有千丝万缕的关系。

这一节，咱们就把它彻底讲透。

4.1 溢出中断机制

ARMv8的PMU计数器是32位或64位的。32位计数器最多数到2^32-1，也就是约42.9亿个事件。你想想看，如果监控的是CPU周期，一个2GHz的核跑一秒就是20亿个周期，不到两秒计数器就溢出了。

溢出中断，就是计数器从最大值翻回0的那一刻触发的。嗯，这里要注意：ARMv8的溢出中断是边缘触发的，不是电平触发。这意味着中断信号只在溢出发生的那个时钟周期有效，如果你没及时处理，它就丢了。

核心机制：PMU计数器溢出时，PMUOVSR（Overflow Flag Status Register）中对应的位会被置1。如果PMINTENSET（Interrupt Enable Set Register）中对应的中断使能位也是1，就会向GIC（Generic Interrupt Controller）发送一个中断信号。

我在项目中遇到过一个问题：某个计数器配置成监控L1 cache miss，结果中断触发频率极高，系统响应延迟飙升。后来怎么解决的？我调整了预分频器，让计数器每4个事件才加1，这样溢出频率就降下来了。

溢出中断的触发条件其实就三个：

  • 计数器达到最大值——32位计数器是0xFFFFFFFF，64位是0xFFFFFFFFFFFFFFFF
  • PMINTENSET对应位已使能——没使能的话，溢出只是置位标志位，不会产生中断
  • PMCR.E位为1——全局使能，这个容易忘

注意：PMU中断的优先级建议设置为比普通外设中断高，但比时钟中断低。我曾经在一个项目中把PMU中断优先级设得过高，结果导致调度器无法正常切换任务，系统卡死。这个坑，踩过一次就记住了。

4.2 中断服务程序编写

写PMU的中断服务程序（ISR），跟写普通外设中断不太一样。最大的区别是：PMU ISR里要处理的事情特别多，而且必须在中断上下文中完成，不能推迟到下半部。

为什么？因为溢出标志位如果不及时清除，下一次溢出来了，你根本不知道。我个人的习惯是：ISR里只做最必要的事，其他统计、日志、通知都放到任务上下文里做。

一个典型的PMU ISR流程如下：

  1. 读取PMUOVSR——判断是哪个计数器溢出了
  2. 保存溢出计数——把溢出次数累加到全局变量中
  3. 清除溢出标志——写1到PMUOVSR的对应位
  4. 可选：重新加载计数器——如果需要周期性采样，就重置计数器值
  5. 通知上层——通过信号量或消息队列通知统计任务

来看一个实际的代码示例。这是我在一个ARM Cortex-A72平台上用的ISR模板：

// PMU中断服务程序示例
void pmu_irq_handler(void) {
    uint32_t overflow_status;
    uint32_t counter_index;
    
    // 1. 读取溢出状态
    overflow_status = read_pmuovsr();
    
    // 2. 遍历所有溢出的计数器
    while (overflow_status) {
        counter_index = __builtin_ctz(overflow_status);  // 找到最低位的1
        
        // 3. 累加溢出计数
        g_pmu_overflow_count[counter_index]++;
        
        // 4. 清除溢出标志（写1清除）
        write_pmuovsr(1U << counter_index);
        
        // 5. 如果是周期采样模式，重新加载计数器
        if (g_pmu_mode[counter_index] == PMU_MODE_PERIODIC) {
            write_pmcntenset(counter_index, g_pmu_period_value[counter_index]);
        }
        
        overflow_status &= ~(1U << counter_index);
    }
    
    // 6. 通知统计任务（使用信号量）
    osSemaphoreRelease(g_pmu_semaphore);
}

小技巧：用__builtin_ctz()（Count Trailing Zeros）来快速定位溢出的计数器位，比逐位判断快得多。我在性能敏感的ISR里一直用这个。

这里有个容易忽略的点：PMUOVSR的清除是写1清除。如果你不小心写了0，标志位纹丝不动。我刚开始写PMU驱动时就犯过这个错，查了半天才发现是清除方式不对。

另外，ISR的执行时间要严格控制。PMU中断可能很频繁，尤其是监控高频事件时。我建议在ISR里不要做任何打印、加锁、或者复杂运算。把这些事留给任务上下文。

4.3 多核PMU同步

多核系统里，PMU同步是个大难题。每个核有自己的PMU计数器，它们之间没有硬件同步机制。你想想看，如果核0和核1同时监控L2 cache miss，它们的计数器值可能差很多——因为每个核的cache行为本来就不一样。

但有些场景下，我们需要全局的统计视图。比如整个系统的IPC（Instructions Per Cycle），或者所有核的总功耗估算。这时候就需要多核PMU同步。

我总结了几种常见的同步策略：

同步策略 实现方式 适用场景 开销
软件触发同步 通过IPI（核间中断）同时启动/停止所有核的计数器 需要精确时间对齐的采样 中等
周期同步 每个核在固定时间窗口内独立采样，最后汇总 长时间统计，不需要精确对齐 低
硬件事件同步 利用PMU的链式计数或外部触发信号 硬件支持的特殊场景 低
全局计数器同步 使用系统级计数器（如Generic Timer）作为时间基准 需要跨核时间戳对齐 低

我个人最常用的是软件触发同步。具体做法是：

  1. 选择一个主核（通常是核0）
  2. 主核通过IPI向所有从核发送"准备采样"消息
  3. 所有核收到消息后，在同一个时间点（比如下一个时钟中断）同时启动计数器
  4. 采样结束时，主核再次发送IPI，所有核同时停止计数器
  5. 每个核把本地计数器的值上报给主核，由主核汇总

关键点：IPI的延迟通常在几十到几百纳秒级别。如果你的采样窗口是毫秒级的，这个延迟可以忽略。但如果采样窗口只有几微秒，IPI延迟就会引入显著误差。这时候就要考虑硬件同步方案了。

我曾经在一个8核Cortex-A76平台上做性能分析，需要精确测量每个核的cache miss率。一开始我用周期同步，结果发现核间的数据差异很大。后来换成软件触发同步，数据才稳定下来。原因是什么？因为周期同步里每个核的采样窗口起始时间不同，导致cache warm状态不一样。

多核PMU同步还有一个容易踩的坑：计数器溢出同步。如果某个核的计数器在采样窗口内溢出了多次，而其他核没有溢出，汇总时就会出现数量级上的误差。我的做法是：在ISR里记录每次溢出的时间戳，汇总时按时间戳对齐。

多核PMU同步流程 主核 (核0) 从核1 从核2 ① 发送IPI ② 同步启动计数器 ② 同步启动计数器 ② 同步启动计数器 ③ 采样窗口（所有核同时运行，独立计数） ④ 发送IPI停止 ⑤ 汇总数据

避坑指南：我曾经在一个项目中，从核的PMU中断优先级设置得比主核低，结果主核的IPI被从核的PMU中断阻塞了，导致同步失败。后来我把所有核的PMU中断优先级统一设置，问题才解决。多核系统里，中断优先级的一致性很重要。

最后说一个实战经验：多核PMU同步的精度，很大程度上取决于中断响应时间的一致性。如果某个核因为cache miss或者TLB miss导致中断响应延迟，这个核的采样窗口就会比其他核长。我的做法是：在采样窗口开始前，先执行一段"热身代码"，把关键代码和数据都加载到cache里，减少中断响应时间的波动。

← 上一章 📖 返回目录 下一章 →