INTEL x86服务器体系架构（四）

雪瀑牵裳

IT 老棒槌

关注他

34 人赞同了该文章

CHA和cache

上一期，讲到了虚头八脑的知识体系结构。

这个知识体系范畴说虚也虚，说实也实。在年轻的时候，我也特别不屑这种抽象体系。但是等个人经验（格物）积累到一定程度，就对其有所感悟了（致知）。

举个现实的例子，某人，两个月前还是个x86小白。就是通过这个知识体系结构开始学习，两个月后能够从寄存器原理上推断出某司的服务器诊断工具所提供的解析结果是错误的；也能通过x86架构知识来推导某些冷僻参数在CMOS的目录位置。

再举一个关于自己的惨痛例子。其实我现在最后悔的是，当年上大学时对计算机应用学科特别重视，而对基础学科重视不够。尤其各种数学，当时不过混个考试通过而已。

如今二十年过去了，我当年所重视的应用课程，例如什么C语言、面向对象等，现如今都已经成了初中毕业、高中毕业后的社会职业培训课程了。再靠这类应用课程内容吃饭，顶多就是个IT民工。而如今如火如荼的AI，打入门都是从模糊数学、算法讲起。此时我再想深入接触，感觉连都看都看不明白了。不禁感慨，难道自己真的要落伍了么？

基础知识的积累真的是太重要了，就像是房子的地基。个人掌握的基础知识深厚程度，未来会直接决定应用知识学习的高度。

所以现在，虽然我也会为上小学的孩子报一门计算机类的课外辅修课程，但是我一直告诫他，这些课只是给他开拓一下眼界而已。目前阶段，学好语数外，打好基础是最最重要的。

再回到这个专题，上期文档中所说的知识体系，其实不过是知识体系的基础，甚至还未涉及到人员、渠道、外围接口等知识体系的几大要素呢。这些要素同样非常的重要。例如，没有老师，我的好多知识点就只能通过自己的联想和假设，只能通过以后的时间和鲜血来印证，这无疑是知识成长的一大障碍。（师者，所以传道授业解惑也。）

后面的内容中会逐渐暴露出这一点，我在今后的内容中也会列出未自己的想法和未验证的猜测。（学而不思则罔。）

另外即使是算作资料体系，其实也还没包括其他两个重要分支：诊断和调优。如果将来有时间，将会再开这两个子写列。

接着上篇留下的尾巴讲。

一、SKXCPU内部架构

CPU内部的逻辑图如下：

上图中，除了core以外，所有的模组都属于uncore modules。

首先intel资料里一句话要强调一下：“skx CPU可以支持地址空间 48 bits，物理地址空间 46 bits。”。——这句话，我的理解有2：

1、目前x86的64位还不是真正的64位，而是32位的扩展。内存物理空间46bits>32bits。CPU里好多寄存器还都保留着32位的影子，例如内部好多csr寄存器还是32位的；例如好多MCA寄存器仍然以IA32来开头。

2、另外这里的地址空间指的是虚拟地址空间也就是线性空间。这句话又牵扯到后期linux 内核部分的线性空间与物理空间的转换（MMU四层寻址）。

各个部件说明：

一、Mesh/Mesh stop

上面图中 左右双线绿色的通道/上下双线蓝色，形成了一个个方形渔网网格，类似于下面这样一个一个方形小单元：

Intel将这个方形小单元叫做Mesh interconnect。

但是我手头的intel资料描述里，这个mesh结构的直接部件也就是个Meshstop，且资料里也没对这个meshstop说出个实际的功能1，2，3；只是说这个mesh架构与UPI连接有密切关系。另外后续相关的寄存器诊断中，基本看不到涉及mesh的相关内容。

但是如果我们将前一代broadwell CPU和Skylake CPU的结构图对比看，我们可以发现：

前一代的CPU的core/uncore部件之间是基于两个loop ring的；

而Skylake CPU core/uncore部件之间已经是基于这个Mesh网格了。

——所以从理论上说，core到最远uncore部件的路径在skylake CPU上被缩小了。所以理论上性能也提高了。

二、Cores

一个物理cpu socket 内部的多个核，这个核就是core，这个核就是以前我上大学时课本里CPU的范畴。后来intel一个cpu包括了多个核，以及这个模块、那个模块的，所以如今你大爷仍然是你大爷，CPU却已经不是原来的CPU了。

所以在这里规范一下我的X86架构和linux内核两个系列中的相关名词定义：

Socket：是指物理的一个CPU，就是那个实实在在的能拿在手里砸你脑袋的小板砖。例如一个2路服务器，有两个socket，那么在其第一层Linux操作系统里，一个socket对应一个physical ID。

Cores：一个socket内部的多个处理核心。例如同样是上面这个2路服务器一个socket CPU有16 cores，那么在个2路服务器共有32 cores。在其第一层Linux操作系统里，一个socket 的core对应该phsical ID下的一个core ID:

physical id 0的coreID 0~15；

physical id 1的coreID 0~15；

Processor：如果bios里打开的超线程，一个core 又变成了两个逻辑，每个逻辑被称为一个processor。那么随着上面的例子，打开了超线程情况下，该2路服务器的redhat操作系统看到了64个 processor。在redhat的proc/cpuinfo里processor对应着一个processor。这个proessor的编号稍微复杂一些，coreid根据超线数量做了一次interleave。呃，具体的，自己去看操作系统的说明吧。

我们再从操作系统回到硬件层面，硬件层面架构以及寄存器诊断只看到socket和core，所以有时候，某些司的服务器底层硬件日志中出现了proc这个关键字，而“proc”又代表了core……到时候怎么办？扳着手指头数数吧……

至于skx系列的CPU类型和CoreNums 甩出个图，不多说了：

又分铂金系列、金牌系列、银牌系列、铜牌系列——这是从网上找的图，相关的内容归售前死记硬背狂喷去吧，对错我也不care。

Core里相关的寄存器说明，在以后的寄存器部分详细说。

三、CHA与CACHE

FLC又叫一级缓存， 分为 DCU（data） and ICU（instruction）， FLC就是core内的L1 cache。上面这个图没有标识出。

MLC又叫二级缓存，就是 core 外部的L2 cache（skylake将MLC放到了core外）。由CHA部件管理。

LLC又叫三级缓存，就是 core外部的L3 cache。

CHA 包括了以下部分的功能：

1、 cache管理——就是CHA的C了，就是之前Broadwell资料中对应的cache agent（CBO）。用来保存一些cache的meta信息，管理LLC和MLC。

CBO里有一个很重要的TOR_table,来保存core的未完成的transactions;

TOR_table 示意图如下：

未来，我们会接触到很有名的“三振超时”故障，原因是：有长时间的transactions占用core、且无法切换出core。该故障其中的一个关键字就是TOR_TMOUT。（当然MLC里也有对应寄存器报错）

2、 core与内存控制器imc的接口。——就是之前的host agent。

3、 另外，skylake加入了新的子部件 snoop filter来实现/优化core与其他core之间的cache数据同步；

所谓的优化，我的理解是：snoop filter里面有个表数据结构，记录同一块数据所关联的core；如果有cache同步的需求，request从过去的闭着眼广播模式转变成了Point to target的模式，这样就减少了总线负载。

在skylake架构中，CHA是分布到每个core上的，CHA的编号与core的编号相同。——这点与上一代的broadwell/haswell不同。CHA、MLC部分涉及到相关的cache策略，所以是服务器性能调优的重要组成部分。

Cache调优的关键字：prefetch，或stream。CMOS的某些设置项与其有直接关联。

另外CHA、MLC相关寄存器又涉及到服务器诊断尤其是IERR错误诊断。

关于CHA、MLC的疑惑和猜想（18年12月立碑）：

1、 在CHA部分中LLC的描述为11-ways；MLC的描述为8-ways。——cache是一个存储空间，cache有什么11路和8路之说？这种说法究竟是个什么意思？

19年3月的回答：

这个要从cache的数据结构说起。

Cache的数据结构分成两层：

每一级cache，内有多个相等的set。

Set：又叫组。每个组里有多个line。

line：是cache数据调入调出的原子单位。Line的大小又叫linesize。Linesize一般是64B的倍数。我记得skylake CPU的linesize是256B。

一个set组包括多少个line——专业的说法叫 多少个way 同组。

这里的11-ways，8-ways，就是指 每个set里有11个line，或没个set里有8个line。

2、 根据intel EDS的暗示，CHA似乎分成了三个组

CHA0，3，6，9，12，，，，，

CHA1，4，7，10，13，，，，，

CHA2，5，8，11，14，，，，，

——CHA以3为interleave分布在三个组。

目前看skylake最多32个core，那么每个CHA组的成员上限是11个，那这个11是不是就是问题1里面的11-ways？

3、 我曾在一个LINUX crash分析案例中看到，如果cpu里的某个进程出现了一个spinlock死锁，那么我们可以以常量NUM_INVALID_TLB_VECTORS为interleave，通过进程当前的CPUID%NUM_INVALID_TLB_VECTORS得到的余数来获得同组相关的CPU编号，从而得到需要同时flush TLB的CPU组，从而找到spinlock可能影响的CPU们，以及上面的进程。

——这个Flush TLB组和这个CHA组是否有关联？

——此处立个墓碑，等以后寻找答案了。

发布于 2019-03-27 13:43