非2的幂次Cache组大小：Ryzen 7 1800X L2 DTLB关联度及索引计算疑问

1. CPUID返回8路关联与1536条目不冲突的原因 #

• 你的初始推测存在逻辑偏差：TLB总条目数 = 路数（关联度） × 组数，3的素因子完全可以落在组数字段，不需要路数携带3的因子。代入参数计算可得 1536 = 8 × 192，192组刚好包含3的因子（192 = 3 × 64），和你测得的8路关联结果没有任何冲突。
• 你的CPUID解析逻辑是正确的：AMD架构编程手册中，0x80000006 功能号EBX寄存器的位28~31对应L2 TLB关联度编码，值为6时确实对应8路关联，位16~27返回的条目数1536也和公开参数一致，两组参数都是准确的。
• 补充说明：Zen1架构的L2 DTLB设计本身就是针对4K页的1536条目8路组相连规格，不存在参数错误。

2. 非2幂组数的高效索引实现 #

192组确实不是2的整数次幂，AMD在硬件层面采用了两种常用优化方案实现单周期索引计算，效率和2的幂取模基本一致：

• 子块拆分并行查询：将整个L2 DTLB拆分为3个独立的、每组64条（2^6，是2的幂）的8路组相连子TLB，总容量为 3 × 64 × 8 = 1536。查询时用虚拟地址的低6位作为每个子块的组索引，同时并行查询三个子块的对应组，命中的子块直接返回物理地址，整个过程不需要额外的计算延迟。
• 固定模数的硬件快速取模：对于固定模数192，只需要取虚拟地址的低8位（192 < 2^8=256），通过简单的组合逻辑判断：如果低8位的值≥192，则减去192得到索引，否则直接用低8位作为索引，整个运算只需要少量门电路就可以在单周期内完成，不存在性能损耗。

注：Zen系列架构的缓存、TLB设计多次采用非2幂组数的配置，都是通过上述两种方式实现高效索引，不会对访存性能产生负面影响。

测试程序说明 #

你提供的CPUID读取程序逻辑完全符合AMD的架构规范，兼容MSVC和GCC编译器，读取到的参数结果是准确的，代码如下：

#include <iostream>
#if defined(_MSC_VER)
    #include <intrin.h>
#elif defined(__GNUC__)
    #include <cpuid.h>
#endif

using namespace std;

unsigned cpuid( unsigned (&cpuidRegs)[4], unsigned code, unsigned ex );

int main()
{
    static unsigned const SHORT_WAYS[0x10] = { 0, 1, 2, 0, 4, 0, 8, 0, 16, 0, 32, 48, 64, 96, 128, (unsigned)-1 };
    unsigned regs[4];
    cpuid( regs, 0x80000006u, 0 );
    unsigned n = regs[1] >> 16 & 0xFFF, ways = SHORT_WAYS[regs[1] >> 28];
    cout << "L2 D-TLB: " << n << " / " << ways << " ways" << endl;
}

 inline
unsigned cpuid( unsigned (&cpuidRegs)[4], unsigned code, unsigned ex )
{
#if defined(_MSC_VER)
    __cpuidex( (int *)cpuidRegs, code, ex );
#elif defined(__linux__)
    __cpuid_count(code, ex, cpuidRegs[0], cpuidRegs[1], cpuidRegs[2], cpuidRegs[3]);
#endif
    return cpuidRegs[0];
}

内容的提问来源于stack exchange，提问作者Bonita Montero