性能计数器基础：PMU架构、常见性能计数器与访问方式

各位同学，咱们今天聊聊性能计数器。这东西听起来有点枯燥，但说实话，它是我做嵌入式调优时最趁手的工具之一。没有它，你就像在黑暗中摸索——代码跑得快不快、卡在哪，全靠猜。

性能计数器是CPU内部的一堆硬件寄存器。它们能记录各种事件的发生次数，比如执行了多少条指令、发生了多少次缓存未命中。这些数字，就是系统性能的“体检报告”。

PMU架构：性能监控单元的内部结构

PMU（Performance Monitoring Unit）是CPU内部专门负责性能监控的硬件模块。我最早接触PMU是在ARM Cortex-A系列上，当时为了定位一个诡异的帧率抖动问题，折腾了两周，最后靠PMU数据锁定了L2缓存冲突。

PMU的核心组件包括：

• 事件计数器：一组可编程的硬件计数器，每个可以配置为监控特定事件
• 事件选择寄存器：决定每个计数器监控哪种事件
• 控制寄存器：启动、停止、复位计数器
• 溢出中断逻辑：计数器溢出时触发中断，用于长时间采样

不同架构的PMU实现差异很大。我整理了一个对比表：

架构	计数器数量	可监控事件数	特殊特性
ARM Cortex-A	6个通用 + 1个周期	200+	支持链式计数（64位）
x86/Intel	4-8个通用	300+	支持PEBS（精确事件采样）
RISC-V	可配置（通常4-8个）	架构定义+自定义	SBI接口标准化

嗯，这里要注意：计数器数量是有限的。你不可能同时监控所有事件，得学会取舍。我个人习惯是先做一次“扫描”——用不同的计数器配置跑几轮，找出最可疑的瓶颈。

常见性能计数器：Cycle、Instruction、Cache Miss

这些计数器是调优的“三驾马车”。咱们一个一个说。

Cycle计数器

记录CPU运行的时钟周期数。说白了，就是时间。但注意，它不一定是墙上时间——如果CPU有动态调频，Cycle数需要结合频率才能换算成真实时间。

我在项目中遇到过一个问题：两个算法实现，一个Cycle数少但Cache Miss多，另一个Cycle数多但Cache Miss少。你猜哪个更快？答案是后者。因为Cache Miss会导致CPU停顿，实际耗时更长。

Instruction计数器

记录执行了多少条指令。这个数字能帮你算CPI（Cycles Per Instruction）。

公式很简单：CPI = Cycle数 / Instruction数

CPI越低越好。理想情况下，CPI接近1.0。如果CPI大于3，说明你的代码大概率在等内存。

Cache Miss计数器

这个最常用，也最容易被误解。Cache Miss分L1、L2、L3三级，每一级的代价不同。

• L1 Miss：代价约10-20个Cycle
• L2 Miss：代价约100-200个Cycle
• L3 Miss：代价约300-500个Cycle（还要走内存总线）

你想想看，一次L3 Miss的时间，够CPU执行几百条指令了。所以优化Cache Miss，往往比优化指令数更有效。

计数器访问方式：从寄存器到工具链

访问性能计数器有三种主流方式。我按从底层到高层的顺序讲。

方式一：直接读寄存器

最原始的方式。在ARM上，用PMCCNTR读Cycle数，用PMXEVCNTR读事件计数器。需要在内核态或使用特殊指令。

// ARM Cortex-A 读取Cycle计数器示例
uint32_t read_pmu_cycle_count(void) {
    uint32_t value;
    asm volatile("mrs %0, PMCCNTR_EL0" : "=r" (value));
    return value;
}

// 读取事件计数器（需先配置）
uint32_t read_pmu_event_count(uint32_t counter_id) {
    uint32_t value;
    // 选择计数器
    asm volatile("msr PMSELR_EL0, %0" : : "r" (counter_id));
    // 读取计数值
    asm volatile("mrs %0, PMXEVCNTR_EL0" : "=r" (value));
    return value;
}

方式二：使用perf_event系统调用

Linux内核提供了perf_event_open系统调用。这是最推荐的方式——内核帮你处理了权限、上下文切换、多核同步等问题。

// 使用perf_event_open监控指令数
#include <linux/perf_event.h>
#include <sys/syscall.h>

int setup_perf_counter(void) {
    struct perf_event_attr pe;
    memset(&pe, 0, sizeof(pe));
    pe.type = PERF_TYPE_HARDWARE;
    pe.size = sizeof(pe);
    pe.config = PERF_COUNT_HW_INSTRUCTIONS;
    pe.disabled = 1;
    pe.exclude_kernel = 1;
    pe.exclude_hv = 1;
    
    int fd = syscall(__NR_perf_event_open, &pe, 0, -1, -1, 0);
    if (fd == -1) {
        // 处理错误
    }
    return fd;
}

方式三：perf命令行工具

日常调试用这个就够了。简单、快速、不用写代码。

# 统计程序执行期间的指令数和Cycle数
perf stat ./my_program

# 输出示例：
# 1,234,567,890  cycles
# 987,654,321  instructions
# 123,456,789  L1-dcache-load-misses
# 2.345678901  seconds time elapsed

我个人习惯先用perf stat做快速评估，发现问题再用perf record做详细采样。

PMU工作流程与计数器配置

下面这张图展示了PMU的典型工作流程。从配置计数器到读取数据，每一步都有讲究。

这张图把流程串起来了。你可能会问：为什么要把“停止计数”单独列出来？因为很多新手犯的错误就是——代码跑完了才想起来没读计数器。嗯，我也干过这种事。

计数器配置的实战要点

配置计数器时，有几个坑我踩过，分享给大家：

1. 计数器复用：如果事件数超过计数器数，需要分多次运行。我一般先监控全局事件（Cycle、Instruction），再针对性地监控Cache Miss。
2. 上下文切换：多任务环境下，计数器会被其他进程干扰。解决方案是绑定CPU核心，或者使用per_event的exclude_kernel选项。
3. 溢出处理：32位计数器很容易溢出（以1GHz频率算，4秒就溢出了）。要么用64位计数器，要么定期读取并累加。