|
关于知识体系。 2019年西方新年的伊始，本来是想先从Linux 内核系列写起，按照内核stack写一个从上至下的系列，当写到最底层，就自然而然的操作系统进入了Intel x86架构。可是intel 寄存器、intel架构的参考资料，以及学习笔记就在手边，脑子里的相关的思路也比较清晰，所以就以X86服务器intel架构开篇吧，爽一下朋友圈里还玩技术的兄弟们。 不要问我文章是不是原创了——肯定是原创。若不是原创也不好意思发出来，若不是原创也不好意思评论某些产品的优缺点。 可是正是原创，所以在文档中难免会存在错误。 要知道，相关的这些内容，我目前所在的某司是没有这种系统培训的。所以，我也没有捷径从其他大神那里直接获得正确的知识。我不得不靠一些工作中的关系以及平日积累的文档，自己默默躲在角落里啃骨头。知识体系的建立过程，就像下面的方法论一样： 学->立->破->学->立->破->学->立…… 当螺旋式的轮回个三圈， 我想我也能成为一个伪大神了吧。 洗脑的方法论不算太久以前，我曾从redhat的一篇文档里看到了一个抽象化的troubleshooting方法论，这副图很好： 上面这副图，仿佛又将我带到了年轻时在夕阳下奔跑的时代。只因这副图居然和我在HP曾参加过的troubleshooting soft skill的内容是一样一样的。——原来各个IT巨头所使用的基础方法论，都是一样的，多年未变。 最近，我又从intel的文档里又看到了intel的诊断思路方法论，这个图更好： ——其实intel这副图和上面redhat的这副图，本质是一样的。intel这幅图更好的地方在于：明确了如果假设不成立的情况，我们的思维路径。 这一部分的内容，本想放到后面 intel skyX cpu 寄存器诊断里讲。在这里先引用一下，首先是表明我是做苦逼售后出身。然后想说，我的学习过程从过去到现在乃至到将来，按照上面的这两幅思维导图： 1、 自己看资料和琢磨相当于“信息收集”。 2、 而目前所写下的技术文档，相当于“确定假设”、也就相当于“立”。 我一直认为：“假设”可能会错，但确立假设毕竟是认知过程的里程碑，总比一直混沌迷糊脑中空空要强好多。——正如亚里士多德的好多“假设”，从现在的高度来看都是错的，甚至是可笑的，但是总不能掩盖这些“假设”在那个时代的里程碑意义。 3、 将来我肯定会发现里面存在的错误；或是已走在前面的大神们，在看文档的时候，能发现我的“假设”有错，请指出、并帮我破而再立，跪谢。就如同intel debug方法论中向上反馈的那个箭头(if it is no, Formulate New hypothesis) 。 Intel 服务器Xeon cpu的历史一说到某某的体系架构，一般都是从Long long ago, 从祖坟当年的那根草开始。原因无外乎两点，第一点，大家都喜欢听故事，一个枯燥的Topic多半要从讲历史故事开始，才能多吸引一些人气。否则，一开始就开始讲枯燥无味的技术，说到半截，寥寥几个听众却都跑去看旁边的钢管舞，讲的人多少有些尴尬。另一点，有时是为了给自己一些信心，装作德高望重的样子，字里行间暗示自己是个老不死，呃，老衲是你师傅的战友…… 可是摸着良心说，我真的不能算和x86服务器很相熟。毕竟从前我是搞小机和存储的。就借着之前的高度和相通的一些经验来看待x86 intel架构吧。 我曾经听过司内一些人讲intel 的xeon cpu的发展，我觉得bra bra一通摆活，还不如下面这副图来的痛快： 上图所谓的 haswell，broadwell,skylake等等就是intel Xeon的cpu代号； Grantley,Purley,whitley 是intel 平台代号； CPU代号，代表着某一代CPU； 平台代号，代表搭配某一代CPU的主板chipset结构； 主板Chipset结构，以PCH的型号为主要代表;比如，Purley平台的PCH是c620，外号Lewisburg；（Grantley 平台的PCH是c610 外号Wellsburg）； 上图后面的红框，明显画的很糙，对，那是我后画的。因为似乎Intel从14nm到10nm生产工艺升级的过程中，出现了很多故事，后面的路线图也变来变去。例如，网上某论坛有说，从Intel skylake 14nm往后，intel 想直接推10nm，结果好像制程除了点问题（“晶体管做太小确实会加重量子隧穿效应导致漏电？”——网上的传言不明觉厉）,所以临时改了后面的路线图。我根据各种信息补画了后面的图，补充的内容究竟是对错，要看未来产品发展。 CPU的指标里常说的，具体某款cpu的型号，多少核，多少线程，多少Mhz，多少功率；各种平台的指标里还有CPU sock接口类型，多少针等等。这些指标还是查表吧，我背不下来啊。 我接触X86架构的时间点，沾了点Grantley 尾巴，重点是在purley平台，所以后面的内容基本都是基于purley平台+skylake CPU的范围。偶尔出现一些Grantley平台+haswell的内容，也是为了和skylake做个对比。 啥叫PCHPCH全称为Platform Controller Hub。 不知从哪一代开始，intel xeon CPU就将快速IO设备例如内存控制器（IMC）和PCIE root port（IIO root port）等部件集成到了cpu内部，intel称为 cpu uncore modules；——也有人将以上内容说为：目前的intel cpu集成了北桥。 而一些慢速设备，例如sata磁盘接口，usb接口，主板集成网卡等io设备，一股脑的扔给了PCH上。PCH作为中控，直接连接这些慢速设备——所以也有人说PCH就是传统的南桥。（当然PCH本质上也可以认为是多个PCIE Lanes，所以也可以有PCIE root port）。 打个比方，intel CPU就相当于中央朝廷，PCH就相当于安西都护府。 皇帝看着顺眼的(速度快的IO)放在朝廷里（CPU uncore部分）任职； 皇帝看着不顺眼的（速度慢的IO）就发配到安西都护府（PCH），由安西都护府负责，然后安西都护府定期给朝廷打个报告。而安西都护府和朝廷之间的沟通通道，就是DMI3——相当于PCIE3x4 lanes（以后描述里，就把lanes这个词省了吧，每次写都累）。 （当然PCH安西都护府也并不是一直处于边缘地位，要知道biosMe也是连接到PCH上的；BMC（ipmitool）是连接到PCH上的。） 以后若有时间，要将PCH的坑补上，毕竟是26个lanes。 PCIE服务器资源三大类：CPU（注意这里是指core），Mem，IO。我个人认为最复杂和最重要的（体验）是IO。说起服务器的IO，肯定聊一聊服务器的PCIE。 如果我们从PCIE角度看，那么一台服务器的PCIE从拓扑连接上又分成了两类： 1、 CPU uncore module里连出来的，圈儿里有人称为直通式PCIE； 2、 PCH 连出来的，圈里有人称为非直通式PCIE、或叫绕路PCIE； 所以在相同的PCIE Gen、相同的PCIE lanes数的条件下，理论上说，非直通式PCIE口有可能出现性能不如直通式PCIE的情况。 什么是PCIE lane？”车道”也。具体的说明查百度吧。 另外，PCIE的长相，自己查百度吧。——我一直是不相信长相，因为明明只能提供M lanes 却做成N lanes的长相，这种事儿好像也在市面上出现过的。 tips扩展想象：所以，若某些客户，片面的要求所有的PCIE槽位都配置快速的PCIE设备（例如GPU运算卡），如果服务器设计不严，有没有可能出现性能问题？。。。。。。 另外关于PCIE标准协议的分层以及三大空间的详细说明，将放到后续的intel x86 寄存器诊断中讲吧。 操作系统/BMC/BIOS如何确定某个PCIE的地址？使用俗称的BDF或B/D/F来表明某个PCIE的地址。即： BUS,DEV,FUN。 ——所谓的BDF，牵扯到三个方面： 1、 PCI协议定义 2、 CPU内部bus结构 3、 BIOS对bus的运算编址，（目前看，在bios预先给root bus分配完CPUBUSNO以后， BIOS还是基于最左优化的方式来分配下面的BUSNO的）。 后续的题目再展开。 Intel X86最简单的逻辑图综合以上说明，一个最简单的intel x86 架构如下： 上图是网上某intel 消费级平台的架构图，将上面图中的intel 100 chipset换成C620，差不多就是X86服务器了。 说说知识体系我还记得早年在HP时，头上有位老板Mr. Lv。他在review一位初级技术员工时曾问过这样的问题：请问你会通过什么样的方法来提高专业技术知识能力？ 员工答：我会每天看公司案例库的案例，通过案例学习来提高自己的专业技术知识。 老板点评：你这个回答我不是太满意。案例库里的案例只是前人的经验和一些技巧。如果只学习案例库，那么你仅仅是成为了一个熟练工，知其然却不知所以然。作为一个新人，你应该尽快完成理论学习和培训资料的学习，尽快建立自己的知识体系，这样才能有更高的发展。 （——啊啊，我发誓那个员工不是我，我当时是在老板边上打酱油的。） 体系，泛指一定范围内或同类的事物按照一定的秩序和内部联系组合而成的整体。知识体系往往分层表示，底层为共性的理论基础，为“内”，上层是实际的技术应用技巧，为“外”。 1、所以在我浅薄的认知里，理想的X86服务器制造公司的知识体系应该是这样的： 蓝色区域，代表着Intel的架构基础。褐色区域，代表着某司的服务器产品的特征。 而实际的某司的知识体系却是这样的： 所以，曾经出现一个怪现象：新入职的员工参加产品培训，十多个服务器型号，依次每天讲一种型号。填鸭式的两周，学员最后学的是又累又一团浆糊。没办法，没有基础的新人，搞不清多个服务器型号之间的架构共同点。当然，没有体系化的基础知识，他们也没有那个能力去归纳总结。 2、在我的认知里，服务器的研发部门对服务部门的知识交接应该是这样的： 蓝色的部分相当于研发部门和服务部门之间的共同的平台语言。褐色，代表着产品技术特征。 上面这副图，如果左边蛋换成“厂商”、右边蛋换成“客户”，两个蛋底向下扎入的平台“purley eds”换成 itil，那么这副新图仿佛又带我回到了年轻时代。 那时hp要求现场工程师必须要通过itil认证。 而工程师觉得学这种虚头八脑的方法论屁用没有。 但后来有个老板说过这么一句话：其实itil是it管理的理想化模型，国内几乎没有公司能照搬实现。但是你们学习这门课的实际意义是，你们在和公司其他部门或者客户沟通的时候，能够在同一个理论平台上，用同类的话术，来聊服务那些破事儿。 那我们再返回到当前这幅图。两个蛋蛋扎在同一个平台知识体系的意义也就不言而喻了：双方能用共同的、你懂我也懂得话术，来完成知识资料的交接。 当服务器产品研发部门向服务部门传递产品知识的时候： 首先要将intel 的架构与服务器的逻辑图进行一一对应。 然后再将服务器的逻辑图与服务器的物理图进行一一对应。 然后再介绍该服务器产品的产品特点，再通过该产品所面向的客户群体，再一次突出产品特点。 而实际的某司的知识交接却是这样的： 所以，讲的人照本宣科，听的人例行公事。 客服部门心里想：你就讲这点东西，谁能听懂啊？ 研发部门心里想：给你讲多了，你能懂么？ 所以现实中不可避免的现象：最后在客户那里，除了日志明确指向了某部件……呃，服务部门拉通研发部门的黄继光是第一要务。 当然费心力的扎进平台知识体系，确实没法用最傻白甜的管理指标“投入产出比”来衡量。就如同我等草民又怎能用工时价值体系来衡理论物理科学家是否有投入产出比？ 3、 个人的知识体系建立有两条路： 左边一条从上到下的绿色箭头，即从外到内，格物致知： 右边一条从下到上的绿色箭头，即从内到外，知行合一； 究竟是格物致知还是知行合一？儒家斗了数百年也没争出个1，2，3来。 这里只是应用取其一种说法： 朱程理学推崇“格物致知”，其中的一种解释：不断琢磨外在的东西，最终获得内在的道理。 王阳明心学推崇“知行合一”，其中的一种解释：理在心中。先知理，再通过实践验证理。 只想隐晦的说，有一类公司只让技术员工走格物致知这条路，但是却不给员工提供后续的知识体系层次。所以最后技术员工一直在那里格物，格物，格物，格物，格物，格物…… ——故意还是无意？ 再举个例子： 一家之主， 是让孩子们稍有劳动力就低头在田里耕地？ 还是让孩子们先上个农业大学再投身农业？ ——地主对佃户选择前者。而家长对亲生子女选择后者。 难道古代人治的本质就是愚民？ Skylake CPU内部结构下篇进入skyX CPU的内部，详细说明这些部件。 Cores CHA IIO IMC UBOX PCU MSR CSR 其实，我认为CPU里最好玩的还是PCI BUS，关于这方面连intel都说的云里雾里的，甚至intel文档里都出现了闭着眼抄以前的文档以致抄错的情况。 以上一二三篇，尝试着写意，只因总有人说技术的层次太low。 接下来的四五六篇，将会进行枯燥的SKX CPU内部一日游。 |
|
|
