HN-F（Home Node）计数器详解：请求计数、命中/未命中统计与延迟测量
好，咱们接着聊CMN的性能计数器。上一节我们把HN-F的整体框架搭起来了，这一节我打算深入进去，聊聊HN-F那几个最核心的计数器。说白了，你调试性能问题，十有八九得跟这几个计数器打交道。
我个人习惯，拿到一个性能数据，先看HN-F的请求计数。为什么？因为它能告诉你系统到底有多忙。你想想看，一个Home Node如果请求量上不去，那后面的命中率、延迟分析都无从谈起。
HN-F请求计数
HN-F的请求计数器，主要统计三类请求：
- Read请求：包括ReadOnce、ReadNoSnp、ReadUnique等变体
- Write请求：主要是WriteUnique、WriteLineUnique、WriteEvictFull等
- Atomic请求：像AtomicStore、AtomicLoad、AtomicCompare等操作
每个请求类型都有独立的计数器。嗯，这里要注意，CMN-600和CMN-700的计数器数量不一样，CMN-700多了几个针对DVM（Distributed Virtual Memory）和Stash请求的计数器。
关键寄存器：
HN_F_REQ_RD_COUNT— 读请求计数HN_F_REQ_WR_COUNT— 写请求计数HN_F_REQ_ATOMIC_COUNT— 原子操作计数
我在项目中遇到过一个问题：某个加速器的性能始终上不去，看带宽利用率也不高。后来我查了HN-F的请求计数，发现Read请求和Write请求的比例严重失衡，Read请求占了95%以上。这其实是个信号——写缓冲可能被读请求饿死了。调整了一下QoS优先级，问题就解决了。
HN-F命中/未命中统计
命中率，这是所有缓存系统绕不开的话题。HN-F的命中/未命中统计，其实分两个维度：
- SNP（Snoop）过滤命中：HN-F维护了一份目录，记录哪些cache line可能被其他节点缓存了。如果目录命中，说明需要发snoop请求去其他节点拿数据。
- 缓存命中：HN-F本身也有缓存（HN-F DTC），如果数据在本地缓存中，那就是一次干净的命中。
这两个维度要分开看。我曾经踩过一个坑：只看缓存命中率，觉得90%挺高的，但性能就是上不去。后来发现SNP过滤命中率只有30%，意味着大量请求都要发snoop去远端拿数据，延迟自然就高了。
避坑指南：
我曾经以为HN-F的命中率越高越好，后来发现不是这么回事。如果命中率太高（比如99%以上），反而说明你的工作集太小，可能没有充分利用系统的并行能力。适当降低命中率，让更多请求走内存，有时候反而能提升整体吞吐量。当然，这取决于你的业务场景。
相关的计数器有：
| 计数器名称 | 描述 |
|---|---|
HN_F_SNP_HIT | SNP过滤命中次数 |
HN_F_SNP_MISS | SNP过滤未命中次数 |
HN_F_CACHE_HIT | 本地缓存命中次数 |
HN_F_CACHE_MISS | 本地缓存未命中次数 |
你算命中率的时候，记得用 HN_F_CACHE_HIT / (HN_F_CACHE_HIT + HN_F_CACHE_MISS)。别把SNP的计数器混进去，那俩是不同维度的东西。
HN-F延迟测量
延迟测量，这是性能分析里最让人头疼的部分。HN-F提供了几个硬件延迟计数器，可以帮你定位瓶颈到底出在哪个环节。
延迟测量通常分三段：
- 请求到HN-F的延迟：从RN（Request Node）发出请求，到HN-F收到请求的时间
- HN-F内部处理延迟：包括查找目录、访问缓存、发送snoop等操作的时间
- 响应返回延迟：从HN-F发出响应，到RN收到响应的时间
我个人习惯，先看总延迟，如果总延迟超标，再分段看是哪一段出了问题。你想想看，如果总延迟是100ns，内部处理占了80ns，那问题大概率出在HN-F内部，可能是缓存冲突或者snoop风暴。
实用技巧：
测量延迟时，建议用HN_F_LATENCY_SAMPLE寄存器做采样。这个寄存器可以配置采样周期，比如每1000个请求采样一次。采样频率太高会影响性能，太低又不够精确。我一般设成每10000个请求采样一次，既不影响性能，数据也够用。
相关的延迟计数器：
HN_F_LATENCY_REQ_TO_HNF // 请求到HN-F的延迟
HN_F_LATENCY_HNF_PROCESS // HN-F内部处理延迟
HN_F_LATENCY_RESP_TO_RN // 响应返回延迟
HN_F_LATENCY_TOTAL // 总延迟
每个计数器都支持配置最小、最大、平均值的统计模式。嗯，这里要注意，平均值有时候会骗人。我曾经遇到一个场景，平均延迟只有80ns，但P99延迟到了500ns。如果只看平均值，你会觉得系统没问题，但实际上某些请求已经慢得离谱了。所以，我建议你同时看P99或者P999的延迟数据。
核心逻辑图
下面这张图，是我根据多年经验总结的HN-F计数器分析流程。你照着这个思路走，基本不会漏掉关键信息。
这张图的核心逻辑是：先看请求计数，判断系统是否真的忙；再看命中率，分析数据局部性好不好；最后看延迟，定位具体瓶颈在哪。如果延迟超标，就分段定位，检查缓存冲突或者snoop风暴，然后调整配置，重新测量验证。
嗯，这一节的内容就这些。HN-F的计数器其实还有很多细节，比如针对不同请求类型的独立计数器、针对不同端口的计数器等等。但我觉得，先把这三个核心维度搞清楚，你就能解决80%的性能问题了。剩下的20%，等你真正遇到的时候，再回来翻手册也不迟。