序
近些年，我在阅读一些和处理器相关的论文与书籍，有很多些体会，留下了若干文字。其中还是有一片领域，我一直不愿意书写，这片领域是处理器系统中的Cache Memory。我最后决定能够写下一段文字，不仅是为了这片领域，是我们这些人在受历史车轮的牵引，走向一个未知领域，所产生的一些质朴的想法。
待到动笔，总被德薄而位尊，知小而谋大，力少而任重，鲜不及矣打断。多次反复后，我几乎丢失了书写的兴趣。几个朋友间或劝说，不如将读过的经典文章列出来，有兴趣的可以去翻阅，没有兴趣的即便是写成中文也于事无补。我没有采纳这些建议，很多事情可以很多人去做，有些事情必须是有些人做。
这段文字起始于上半年，准备的时间更加久远些，收集翻译先驱的工作后，加入少许理解后逐步成文。这些文字是留给自己的一片回忆。倘若有人从这片回忆中收益，是我意料之外的，我为这些意外为我的付出所欣慰。Cache Memory很难用几十页字完成哪怕是一个简单的Survey，我愿意去尝试却没有足够的能力。知其不可为而为之使得这篇文章有许多未知的结论，也缺乏必要的支撑数据。
在书写中，我不苛求近些年出现的话题，这些话题即便是提出者可能也只是抛砖引玉，最后的结果未知。很多内容需要经过较长时间的检验。即便是这些验证过的内容，我依然没有把握将其清晰地描述。这些不影响这段文字的完成。知识的积累是一个漫长的过程，是微小尘埃累积而得的汗牛充栋。再小的尘埃也不能轻易拂去。
这些想法鼓励我能够继续写下去。
熙和禺皓的加入使本篇提前完成。每次书写时我总会邀些人参与，之前出版的书籍也是如此，只是最后坚持下来只有自己。熙和禺皓的年纪并不大，却有着超越他们年纪的一颗坚持的心。与他们商讨问题时，总拿他们与多年前的自己对照，感叹着时代的进步。他们比当年的我强出很多。我希望看到这些。
个体是很难超越所处的时代，所以需要更多的人能够去做一些力所能及的，也许会对他人有益的事情。聚沙成塔后的合力如上善之水。因为这个原因，我们希望能有更多的人能够加入到Contributors List，完善这篇与Cache Memory相关的文章。
Cache Memory也被称为Cache，是存储器子系统的组成部分，存放着程序经常使用的指令和数据，这只是Cache的传统定义。从广义的角度上看，Cache是缓解访问延时的Buffer，这些Buffer无处不在，只要存在着访问延时的系统，这些广义Cache就可以在掩盖访问延时的同时，尽可能地提高数据带宽。
在处理器系统设计中，广义Cache的身影随处可见。在一个系统设计中，快和慢是一个相对概念。与微架构(Microarchitecture)中的L1/L2/L3 Cache相比，DDR是一个慢速设备，在磁盘I/O系统中却是快速设备。在磁盘I/O系统中，仍在使用DDR内存作为磁介质的Cache。在一个微架构中，除了有L1/L2/L3 Cache之外，用于虚实地址转换的各级TLB，在指令流水线中的ROB，Register File，BTB，Reservation Station也是一种Cache。我们准备书写的Cache，是狭义Cache，是大家所熟悉的，围绕着处理器流水线和主存储器的L1/L2/L3 Cache。这些Cache组成的层次结构，是微架构的设计核心。
广义Cache的设计可以在狭义的实现中获得帮助，却不是书中重点。在网络与存储这两个热点话题中，算法层面之外的重中之重是广义Cache的管理问题。与云相关的各类概念中，亟需解决的事情依然是算法与广义Cache管理。算法层面的实现需要考虑广义Cache的管理策略，反之亦然。广义Cache与狭义Cache系统没有质的区别。这些Cache系统都是由数据缓冲，连接缓冲的数据通路和控制逻辑这三个部分组成。
从算法角度上看，广义Cache的设计与实现比狭义Cache相比也许略微复杂一些；用实现的角度上看，狭义Cache的设计复杂度远远超过大多数广义Cache。读者也许终其一生没有机会去体验狭义Cache系统的设计，依然可以从这些设计思想中受益。这些思想，可以应用于复杂的处理器系统中，可以解决一些细致入微的性能问题。系统开发者在不断思考探索的过程中，在挑战极限的奋斗中，在身旁最后一把利器寸寸折断后，杀虎屠龙。
我未曾想过书写一篇学术意义上完美的文章。我更愿意用工程师的语言完成写作，这并不阻碍本篇内容的有理可依。所有这些想法使我不堪重负，在整个处理器系统的设计中，几乎没有什么部件比Cache Memory系统更为复杂。
本篇书写的Cache系统以Alpha，Power，UltraSPARC和x86处理器为主线，这四个处理器目前属于Tier 1。虽然Alpha处理器已退出历史舞台，但是并不影响其Tier 1的地位。我不会刻意去书写目前较为流行的嵌入式处理器，because yesterday’s high-performance technologies are today’s embedded technologies, but yesterday’s embedded-systems issues are today’s high-performance issues.
在Tier 1处理器中，本篇偏重于Intel的x86处理器实现，不管有多少资料引证Power和UltraSPARC处理器的诸多优点，x86处理器依然是使用最为广阔，影响最为深远的处理器。单纯从结构上看，Intel的x86，即便是最新的Sandy Bridge EP处理器，也远未到达学术界意义上的完美。但是在Cache Memory层面，Intel的领先是事实。
我最初曾试使用英文书写这些文字，我已经记不清楚最后一次抱着学习的目的去读中文技术类书籍是曾几何时，中文科技类书籍不能如此发展下去。我远没有书写英文小说的能力，依然有使用英文写科普文章的胆子，不用翻译的书写更加惬意。最终放弃了这个选择，因为英文世界里有这样的文章，因为Cache Memory之外的内容，因为中文世界需要有人去贡献一些勇气与智慧。
待到完成，总留有遗憾。我习得从这些遗憾中偷得间隙，留一片空间给自己。书不尽言，言不尽意总是无可奈何。这些文字很难给予我任何成就感，细看先驱的诸多著作后，留下的是何足道后的反思。我安于反思后的平静。
在阅读这些文字前，希望您能够仔细阅读John和David书写的“A Quantitative Approach”。我常备这本书，看了许多遍，字里行间内外的一些细节仍然不慎明了，写作时重温此书有了新的收获，借此重新审读了下列文字。
这篇文章最初的版本是0.01，书名叫浅谈Cache Memory。
第一章
1.1 关于Cache的思考
在现代处理器系统中，Cache Memory处于Memory Hierarchy的最顶端，其下是主存储器和外部存储器。在一个现代处理器系统中，Cache通常由多个层次组成，L1，L2和L3 Cache。CPU进行数据访问将通过各级Cache后到达主存储器。如果CPU所访问的数据在Cache中命中，将不会访问主存储器，以缩短访问延时。
工艺的提高，使得主存储器的访问延时在持续缩短，访问带宽也在进一步的提高，但是依然无法与CPU的主频，内部总线的访问延时和带宽匹配。主存储器是一个不争气的孩子，不是如人们期望那般越来越快，是越变越胖。
主存储器膨胀的形体对Cache Memory提出了更高的要求，也进一步降低了主存储器所提供的带宽与访问延时之间的比率。近些年，单端信号所提供的数据传送带宽受到了各种制约，使得差分信号闪亮登场。差分信号的使用却进一步扩大了访问延时，对于这种现象，理论派亦无能为力，只是简单规定了一个公式1‑1，这只是一个无奈的选择。
从以上公式可以发现，延时在以平方增长，而带宽以线性增长。可以预计在不远的将来，CPU访问主存储器的相对访问延时将进一步扩大，这是主存储器发展至今的现状，这使得在处理器设计时需要使用效率更高的Cache Memory系统去掩盖这些Latency，也使得Cache Memory需要使用更多的层次结构以提高处理器的执行效率。在现代处理器中，一个任务的执行时间通常由两部分组成，CPU运行时间和存储器访问延时，如公式1‑2所示。
在一个处理器系统中，影响CPU运行时间的因素很多，即便是几千页的书籍也未必能够清晰地对其进行阐述。但是即便在一个可以容纳几千条指令的并行执行的CPU流水线中，采用更多提高ILP(Instruction-Level Parallelism)的策略去进一步缩短CPU的运行时间，这些指令也必会因为存储器的访问延时被迫等待。
这使得如何缩短存储器访问时间受到更多的关注，合理使用Cache是降低存储器访问时间的有效途径。根据统计结果，在处理器执行一项任务时，在一段时间内通常会多次访问某段数据。这些任务通常具有时间局部性(Temporal Locality)和空间局部性(Spatial Locality)的特征，这使得Cache的引入顺理成章。这种局部性并不是程序天生具有的特性，是一个精心策划的结果。我们不排除有些蹩脚的程序时常对这两个Locality发起挑战。对于这样的程序，处理器微架构即便能够更加合理地安排Cache层次结构，使用更大的Cache也没有意义。
在一个任务的执行过程中，即便是同一条存储器指令在访问存储器时也可能会出现Cache Hit和Cache Miss两种情况。精确计算一个任务的每一次存储器访问时间是一件难以完成的任务，于是更多的人关注存储器平均访问时间AMAT(Average Memory Access Time)，如公式1‑3所示。
从公式1‑3可以发现在一个处理器系统中，AMAT的计算也许并不困难，只需要能够确定Hit time，Miss Rate和Miss Penalty这三个参数即可。但是如何才能才能确定这三个参数。
在一个程序的执行过程中，精确计算Hit time，Miss Rate和Miss Penalty这三个参数并不容易，即便将计算这些参数所需的环境进行了一轮又一轮的约束。近些年，我在面试一些Candidates的时候，通常只问他们一个问题，让他们简单描述，在任何一个他所熟悉的处理器中，一条存储器读写指令的执行全过程。我很清楚在短暂的面试时间内没有任何一个人能够说清楚这个问题，即便这个Candidate已经获得了处理器体系结构方向的博士学位。
我所失望的是参加面试的学生几乎全部忘记了这些可能在课堂上学过的，可能会使他们受益终身的基础内容。参加面试的学生们更多的是在其并不算长的硕士博士学习阶段，研究如何提高编程能力，和一些与操作系统具体实现相关的技巧。这些并不是学生们的错，有太多的评审官们本身就仅专注于小的技术和所谓的编程能力。
这些具体的编程能力和技巧，本不是一个学生应该在学校中练习的。在弥足珍贵的青春岁月中，学会的这些小技巧越多，这个学生在整个技术生涯中的Potential可能越低。重剑无锋，大巧不公。泱泱大国最为缺少的，不是能够书写程序，实现各类技巧的工程师。
1.2 Cache不可不察
在现代处理器中，Cache Hierarchy一般由多级组成，处于CPU和主存储器之间，形成了一个层次结构，这个层次结构日趋复杂。Intel甚至放弃使用阿拉伯字母对Cache的各级层次编号，而直接使用LLC(Last-Level Cache)，MLC(Medium-Level Cache)这样的术语。
变化的称呼表明了一个事实，Cache层次结构在整个处理器系统中愈发重要，也越发复杂。Sandy Bridge处理器大约使用了十亿个晶体管，在其正中不再是传统的CPU，是Ring Bus包裹着的最后一级Cache [1]。
处理器的制作过程异常复杂。在人类历史上，其设计难度只有古埃及的金字塔可以与其媲美，即便是胡夫金字塔也只使用了230万个巨石，几十万个劳工而已。现代CPU的所耗的资源何止这些数字。在处理器这座金字塔中，Cache层次结构是最基本的框架。
几千年前，孙子曾经说过，“兵者，国之大事，死生之地，存亡之道，不可不察也”。对于有志于站在金字塔顶峰的，即便目标只有半山腰的系统程序员，也是Cache，不可不察也。在Intel的Values->Discipline中有一句话“Pay attention to detail”。
但是不要忘记Devil is in the detail。准备深入理解Cache层次结构的读者需要时刻提醒自己真正了解什么是细节之后，才会重视细节，才能够避免因为忽视细节而引发的灾难。重视细节这个品质与你是否足够细心没有必然联系。
我们回到公式1‑3，简单探讨计算Hit time，Miss Rate和Miss Penalty这三个参数时所需要考虑的因素和相关的环境。
似乎Hit Time参数最容易获得。我们很快就可以从CPU的数据手册中找到各级Cache Hit后的访问时间，并从L1 Cache的访问时间开始计算Hit Time。可能我们上来就错了，现代处理器大多使用了Store-Load Forwarding技术。存储器读操作首先要查询的并不是L1 Cache，是在更前面执行的，还没有来得及提交的Store结果，这些结果保存在一段数据缓冲中，这个数据缓冲也是一种Cache，不过比L1 Cache更加快速一些，也更接近CPU。
除了数据Cache，在现代处理器中，在指令Cache前还有一个Line-Fill Buffer。Sandy Bridge微架构中还含有一个μops Cache[1]，计算指令Cache的Hit延时也没有想象中容易。精确计算指令与数据Cache Hit的延时需要注意很多细节。简而言之，在处理器系统存储层次中，L1 Cache并不是最快的，也不是第一级。如果进一步考虑到Load Speculation使用的各类算法和命中率，Hit Time参数并不容易计算清楚。
即便不考虑这些较为复杂的细节，我们仅从L1 Cache开始，Hit Time参数也很难用简单的公式描述。在单处理器环境中，L1 Miss后会逐级查找下级Cache，直到主存储器。但是在多处理器内核环境中，情况复杂得多，一次存储器访问在自己的内核中没有命中，可能会在其他内核的Cache中命中，在其他内核的Cache中命中后，又存在数据如何传递，延时如何计算这些问题。说清楚这些问题并不容易。如果我们再进一步讨论多个SMP系统间Cache的一致性，这个Hit Time的计算就更加复杂。我只能选择放弃在这一节内，能够清楚地描述如何计算Hit Time这个参数。
Miss Rate参数更加难以琢磨。我们真的可以用Vtune，Perf这样的工具精确计算出哪怕是单个任务的Miss Rate这样的参数吗，用这样的工具得到的统计数值有什么用途。同一片树叶，有的人一叶障目，有的人一叶知秋。不要为一叶障目而苦恼。多看几片后，必会发现春天的到来，也不要为一叶知秋而骄傲，少看几片，终会被最后一片树叶阻隔。
Miss Penalty参数的计算仿佛容易一些。最糟糕的情况莫过于CPU从主存储器中获取数据。我们可以将环境进一步简化，以便于读者计算这个参数。我们可以不讨论SMP系统间的Cache一致性，甚至不讨论SMP之内的Cache一致性，仅讨论单处理器。即便如此Miss Penalty参数也不容易轻易计算，即便在这种情况之下，我们只讨论存储器读。
我们忽略微架构在Cache前使用的各类Queue，让存储器读操作首先对L1 Cache进行尝试。如果没有命中这级Cache，这次数据访问一定可以到达L2 Cache吗，如果不是L2 Cache，又是哪一级Cache。这一切由L1和L2 Cache的关联结构决定。在一个处理器系统中，L1与L2 Cache之间可能是Inclusive，也可能是Exclusive。如果是Inclusive，存储器读操作将接着尝试L2 Cache，如果不是将会跨越这级Cache。事实并非如此简单，L1与L2 Cache并不会直接相连，之间依然存在着许多Buffer。
历经千辛万苦，数据访问最终到达最后一级Cache，如果没有命中，就可以从主存储器中获得数据。在这种情况之下，我们仿佛可以计算出最恶劣情况之下的Miss Penalty。但是这只是噩梦的开始。在现代处理器系统中，每一次存储器读写指令，都是由若干个步骤组成，这些步骤间具有相互联系，如果进一步考虑Memory Consistency层面，所涉及到的同步操作更多一些，这些操作并不能用几句话概括。
我们抛开这些复杂话题，讨论在L1和L2 Cache Miss之后从存储器获得数据这个模型。存储器读从存储器获得数据仅是一次读访问的步骤。从主存储器获得的宝贵数据不会轻易丢失，会存放在Cache中，需要将这些数据存放到哪一级Cache最为合理，LLC，MLCs还是FLC。
在一个正常运行的系统中，在每一个Cache Block中存放的数据都是有用的。新数据存放通常意味着旧数据的淘汰。值得思考的是如何进行这些淘汰操作，使用什么策略进行淘汰。从L1 Cache中淘汰的数据虽然暂时没有用途，但是不意味着可以轻易丢失，是否应该先进入到L2 Cache暂存。采用这种策略时，L2 Cache也需要相应的进行淘汰操作。
从上文的描述可以看到，一个简单的存储器读访问带来了一系列的问题。我们首先需要为这次存储器读做基础的准备，然后进行真正的存储器读，读完成之后，还有复杂的扫尾工作。貌似容易计算的Miss Penalty参数即便在简化到了不能再简化的现代处理器系统中，也很难计算清楚。
我们还没有讨论存储器写对Cache Block的的污染与破坏，写操作可能会改变Cache Block的状态，使存储器读操作更加举步维艰，写操作还会带来很多Bus Traffic，这些Traffic加大了存储器读的Miss Penalty，我们没有讨论多处理器内核环境下的Cache Coherence。
我们依然忽略了一个更加基本的细节，虚实地址转换。在现代操作系统中运行的任务，没有哪个任务可以直接使用Physical Address(PA)，使用更多的是Effective Address(EA)。在多数处理器系统中，EA首先被转换为Virtual Address(VA)，之后再转化为PA。处理器微架构在更多的场景中直接使用的是PA，不是VA更不是EA。
虚拟化技术的引入，在略微有些复杂的VA，PA和EA的基础上又引入了MPA(Machine Physical Address)和GPA(Guest Physical Address)，带来了一系列地址Mapping机制，中断重定向等内容。虚拟化还带来了IOMMU和I/O虚拟化技术。为了能够在最小的篇幅完成这篇文章，我们忽略虚拟化技术，专注最基础的虚实地址转换。
1.3 伟大的变革
虚拟地址的出现可以追朔到上世纪六十年代的Atlas计算系统[2]。在当时Atlas计算系统是一个庞然大物，但也只有96K字节的内部存储器和576K字节的磁鼓作为外部存储器。我们很难深刻体会在计算机发展的初级阶段，计算机使用者的无奈。
当时的使用者可能身兼数职，首先是一个有钱人，不然根本没有机会去购买和使用计算机；然后是一个精巧的工匠，不过打孔技术恐怕已经失传；还必须是一个科学家，需要使用计算机；最后才可能是程序员。
Atlas计算系统所提供的96KB物理地址空间很难满足程序员的需要。在当时程序员被迫显式地管理物理内存与磁鼓之间的数据交换，尽可能地利用外部存储器换入换出一些数据，以扩展物理内存地址空间。这些数据交换挫伤了程序员的编程热情。在这个大背景之下，Atlas计算系统引入了Virtual Memory，同时引入的还有分页机制。
技术的发展趋势惊人相似。在最具智慧的人解决了只有他能够解决的问题后，此后如潮水般涌入的人群爆发式地将其推至巅峰，等待下一位救世主的降临。虚拟地址出现之后迎来了这些变化。
在不到40年的时间里，虚拟存储技术遍及计算机系统的各个领域。从软件层面，多进程的引入顺理成章。与多进程相关的虚拟内存管理机制更加层出不穷，如On-Demand分配策略，COW(Copy On Write)策略等。从硬件层面，多线程处理器已被广泛接收，虚拟化技术更是软硬件层面的集大成者。这些变化已超出虚拟地址引入者的想象。这一切只是变化，或者是变化中的细节，终非变革。
虚拟地址的引入分离了程序员看到的地址和处理器使用的物理地址，设立了一个映射关系表存放虚拟地址与物理地址的映射关系，这个映射关系表也被称之为页表(Page Table)。最容易的想到的是使用主存储器存放这个映射关系表，但是没有程序能够忍受在使用虚拟地址访问一段物理空间时，首先需要从主存储器的页表中获得物理地址。
使用TLB(Translation Lookaside Buffer)作为页表的缓冲是一个不错的想法，很快实现在各类处理器中。TLB一般由多个Entry组成，不同处理器使用的Entry组成结构并不相同。下文以Freescale的E500内核为例简单介绍TLB Entry基本组成结构，如图1‑2所示。
在E500内核的TLB中，一个Entry的必要组成部分包含EPN(Effective Page Number)，RPN(Real Page Number)，TSIZE(窗口大小，通常为4KB)。其中EPN与TIS和TS字段联合组成VPN(Virtual Page Number)[4]；RPN是物理地址基地址；TSIZE记录映射窗口的大小，WIMGE和UWRX为状态信息。
在一段程序访问存储器时，需要进行虚实地址转换。首先需要做的是将EA转换为VA，这个过程因处理器而异，基本过程是VA=f(EA)。函数f可繁可简，x86处理器的处理方法较为复杂。E500内核的做法较为简单，将TS，TID和EA级联即可。
在CPU得到VA后，将与TLB中所有Entry同时进行比较，如果Hit则获得RPN，之后通过简单的计算，最终获得PA；如果Miss，就必须从PTE中进行查找，或者使用软件或者使用硬件手段。这些因为Miss引发的一系列操作会相大程度得影响CPU的执行效率。
TLB最好永远不发生Miss，这要求TLB需要Cover整个主存储器空间，硬件无法容纳这样大的TLB。而且随着TLB的增大，其查找延时也越长，折中的选择是使用多级结构。TLB也因此拆分为L1和L2 TLB，与Cache Hierarchy的结构越发一致。TLB也是一种广义Cache。
多进程的频繁切换为TLB制造了不小的麻烦。在现代处理器系统中，每一个进程都使用各自独立的虚拟地址空间，进程的切换意味着虚拟地址空间的切换，也意味着TLB的刷新。进程的频繁切换导致TLB需要频繁预热，这个开销是难以接受的。这使得PCID(Process Context Identifiers)的引入成为可能。
Intel从Westmere处理器开始支持这一功能[5]。其原理是在TLB Entry中加入PCID，并作为VA的一部分。使用该功能后，进程切换时，没有必要刷新TLB，从而在一定程度上提高TLB的使用效率。E500内核使用图1‑2中的TID字段也可以实现同样的功能。AMD的Opteron微架构使用ASN(Address Space Number)[6]称呼这一功能。采用这种方法在减少TLB刷新操作的同时，进一步提高了函数f的复杂度和硬件负担。凡事有利有弊。
多线程处理器的引入再一次增加了TLB设计的负担。在多线程处理器中，存在多个逻辑CPU。这几个逻辑CPU共享同一条流水线，却使用不同的虚拟地址空间，也需要使用TLB进行虚实地址转换，在绝大多数情况下，这些逻辑CPU共享TLB，对进程切换带来的TLB刷新操作是Zero-Tolerance。这使得Logical Processor ID也加入到TLB Entry之中。
TLB经历若干变化后，其Entry结构日趋稳定，却迎来了更加严厉的挑战。因为主存储器的膨胀速度已经越发不可控制。程序对主存储器容量提出越来越高的要求。这使得主存储器容量几乎以每年100%的速度膨胀，使得TLB的Coverage Rate在逐年降低，直接导致TLB Miss Rate的不断提高。
经典的教科书曾告诉我们，程序的TLB Miss Rate平均值仅为5%左右，在某些情况之下不到1%[7]。而近些年的研究表明，在很多应用中，TLB Miss Rate仅为30~60%[8]。这使得如何降低TLB Miss Rate重新受到关注。
增加TLB的Coverage Rate是降低TLB Miss Rate的有效手段，Coverage Rate指TLB所能管理的存储器空间与主存储器容量的比值。近些年随着主存储器容量的不断扩大，TLB Miss Rate在逐步降低。在主存储器容量不变的前提下，增加TLB的Coverage Rate有两个途径。一是增加TLB的Entry数目，这个数目已经在不断增加，依然无法与膨胀得更加快速的主存储器容量匹配；另外一种方法是增加一条TLB Entry所能Cover的Size。
近期Intel的x86在TLB Size为4K~4MB Hugepage的基础上，提出了1GB Superpage的概念[5]。这一概念并非x86的发明，一些嵌入式处理器，如Freescale的E500内核，很早就使用TLB1[4]支持Superpage，使用TLB0支持常规页面。
增大的页面给操作系统带来了额外的负担。随着页面的增加，应用程序消耗的内存会相应增加，而且相应带来的换页开销也进一步增大。但是如果仅仅面对4K~4MB大小的页面，操作系统仍有能力找到通用策略，FreeBSD从7.0版本起支持4K~4MB大小的Hugepage，Linux也从2.6.23开始为各类微架构提供Hugepage的支持。
真正带来挑战的是1GB之上的Superpage。许多学者与工程人员试图寻求一些Superpage的通用管理策略[9][10][11]，依然难以解决由Superpages带来的Allocation，Relocation，Promotion，Pollution和Fragmentation Control等一系列问题。这使得这些所谓Superpage管理的通用方法几乎停留在纸面上或者实现中，很少有人直接使用操作系统提供的实现机制。
这使得更多的人开始认真思考操作系统是应该继续找寻通用解决方法，还是为专用化与定制化提供服务，是虽千万难吾独往矣，还是耐心等待着水到渠成。Intel将TLB Size直接从4MB跨越为1GB的事实也在暗示着，操作系统需要进一步为应用让步，不再是全面接管，不再是继续制定放之四海而皆准的规则，而是让高效应用按照各自的轨迹前行，是为需要进一步优化的程序提供更大的空间。
Superpages的引入极大降低了TLB Miss Rate。还是有很多人发现TLB地址转换依然存在于存储器读写访问的关键路径上。在多数微架构中，一条存储器读指令，首先需要经过虚实地址转换，得到物理地址之后，才能通过若干级Cache，最终与主存储器系统进行数据交换。如果存储器访问可以部分忽略TLB转换而直接访问Cache，无疑可以缩短存储器访问在关键路径上的步骤，从而减少访问延时。Virtual Cache为此而生，John和David对其情有独钟，Virtual Cache也在MIPS系列处理器中得到了大规模普及，在Pentium 4，Opteron，Alpha21164和有些ARM处理器中使用了Virtual Cache。
采用Virtual Cache不是灵丹妙药，这种方法虽然缩短了存储器访问的关键路径，也带来了Cache Synonym/Alias这些问题，这些问题在SMP和SSMP系统中暴露出了更大的问题。解决这些问题更多需要考虑的是各种软硬件层面的权衡与取舍。
简单介绍虚实地址转换关系之后，我们首先需要关心在一个处理器系统中，存储器读写指令的执行过程。对此一无所知的读者，很难进一步理解Cache层次结构。也正是Cache层次结构的引入，加大了存储器读写指令执行的实现难度。
1.4 让指令飞
Superscalar与OOO(Out-of-order)的引入极大促进了现代处理器微架构的发展。已知的高性能处理器，如Nehalem，Sandy Bridge，Opteron，Power甚至是ARM Cortex系列处理器都使用了这种构架。这类方法在有效提高了ILP(instruction level parallelism)的同时，加大了整个Cache Memory层次结构的实现难度。
在此我们只讨论存储器读写指令在Superscalar与OOO环境下的执行过程。存储器读写指令的执行过程似乎非常简单。即使是只写过几行汇编代码的程序员亦可对此娓娓道来。许多人认为存储器读不过是将数据从主存储器中将数据读入寄存器，存储器写是将寄存器中的数据写入到主存储器中。
这个执行过程很难用一句话回答，即便是将使用的处理器模型进行大规模的约束。在一个支持Superscalar和OOO的处理器中，一条指令的执行被分解为若干步骤。指令首先进入Pipeline的Front-End，包括Fetch与Decode，之后经过Dispatch和Scheduler后进入执行单元，最后Commit执行结果。
假设在一个微架构中，所有指令使用In-Order方式通过Front-End，并采用Out-of-Order方式进行Issue，之后使用Out-of-Order Execution和Completion方式，在最后进行Commitment时使用In-order的方式。其中指令Commitment的定义是在其执行完毕，并将最后结果更新至ROB(re-order buffer)和LSQ(Load-Store Queue)的过程。
现代处理器在Commit最后的执行结果时大多都采用In-order方式，这也保证了指令在经过Out-of-Oder的流水线后，程序员看到的最终结果与程序应有的顺序一致。多数程序员被这一假象迷惑，认为CPU的乱序执行仅与硬件流水线相关，并不会影响软件程序。
事实并非如此。微架构为了实现乱序执行，有些指令，比如存储器读指令，可能会提前执行，而后因为种种原因，如分支预测失败，可能会被迫重新执行。虽然乱序流水线可以保证最后的结果与程序期待的结果一致，但是无法完全抹去这条本不该执行的指令在流水线中，在存储器子系统中留下的执行痕迹。
为了进一步简化模型，我们仅讨论在经过这些约束后的CPU中，存储器读写指令的执行过程。与其他指令相比，这两条指令的执行过程更加显得步履蹒跚。下文以Nehalem微架构为参照说明存储器指令的执行过程。Nehalem微架构Pipeline的组成结构如图1‑3所示。
存储器读写指令在经过Front-End阶段时进行了很多细节处理工作，尤其是对于x86处理器，此处不再对此做进一步的描述。这些存储器读写指令在经过Front-End之后，将首先通过Rename/Allocate部件，使用Renaming技术可以解决与存储器读写最直接相关的WAW，WAR相关，之后等待源Operand准备就绪，并将其Dispatch给Scheduler。这些指令需要从RS(Reservation Stations)获得可用的Entry，对于存储器读写指令还需要从LSQ中预留空间，最后插上ROB Tag的翅膀，经In-Order或者Out-of-Order的发射(Issue)过程，自由飞翔。
这些飞翔的指令无序，而且指令流水线会让最笨的鸟尽可能的提前飞翔。存储器读写指令就是其中最笨的几只鸟。这些飞翔着的存储器读写指令将飞向第一个目的地LSQ，还有一些执行信息会同步到ROB和RS的对应Entry中。
这些飞翔的指令有快有慢，有应该飞的也有不应该飞的。速度不同的指令必须在到达第一个终点LSQ时，按序等待提交。不应该飞的指令必须在最后的Commitment阶段之前被发现，然后被抛弃，重新飞翔。这也造成了在一条指令流水线中存在多个Outstanding的读和写指令，可并行的最大读写指令由ROB，LSQ和RS中的Entry数目决定。在很多现代处理器中，LSQ的Entry数目多小于ROB和RS中的Entry数目，因此在一个Pipeline中可以并发的读写指令首先由LSQ的深度决定。
无序飞翔存储器读写指令在执行过程中，需要尽量无视对方的存在，最大可能的实现飞翔。因此也引入了读写指令的Speculation机制。由于Out-of-Order Issue的原因，后续的指令可能先于之前的指令执行，由于Out-of-Order Execution和Out-of-Completion的原因，率先发射的指令也不一定最先抵达目的地。
这些机制制造了多种乱序的可能。虽然指令的最终结果仍然是In-Order Commitment，但是这一机制并不能保证存储器指令的执行轨迹是in-order的。存储器指令的执行与其执行轨迹的异步引出了一个异常沉重的话题Memory Consistency。这个话题将有专门的篇章讨论。
我们首先分析存储器读写指令的执行过程。这两大类指令都是访问存储器的，虽然一个是进行写，另一个是进行读，但是依然有其相同点。我们首先讨论其相同点。在一个CPU中，读写指令在进入Pipeline之前，首先被分解为两个微步骤或者是两个微指令，这并不是x86处理器所特有的，许多为了提高存储指令执行效率的微架构都使用了这种方式。
其中一条微指令用来计算指令使用的EA。在有些处理器微架构中，每一条Load/Store指令在其之前的Store指令的EA计算完毕后才能发射，这一机制有效解决了存储指令间的RAW类相关，但是这种方式较为Conservative。激进的想法是先做，错了再纠正，只要错误带来的惩罚小于做对了所带来的收益即是一次有效行为。
在现代处理器微架构中，虽然程序员直接使用EA，但是对于存储器读写指令，由于各类寻址方式的引入，Pipeline并不会很顺利地得到最终EA。在x86处理器中，EA的计算公式如公式1‑4所示。
这样的公式显然并不容易很快的计算出结果，这使得现代处理器多设置了AGU(Address Generate Unit)这个专门的执行部件。AGU部件在计算出指令使用的EA后，会将其传递给在LSQ中对应的存储器读写微指令，之后这些微指令才开始真正的存储器操作。
在流水线中指令的执行过程很难用用一句话说清楚。权衡读写指令复杂度后，我们决定先讨论存储器写指令，这条指令的执行过程与读有类似之处，也有很多区别。存储器写指令的第一个目的地是LSQ的对应Entry，这条指令在获得源Operand和EA后，将进行存储器写。在没有描述清楚Cache层次结构之前，我们无法说明存储器写如何在流水线中执行。为未来预留说明空间，我们暂时简化存储器写的执行过程。
任何一个处理器体系结构都会谨慎地处理存储器写指令的执行过程。设计者都明白一个基本道理，如果你向一个指定的存储器写入一个指定的数据后，你很难用常规的手段重新获得其历史信息。写是不能悔棋的，即便其目标是一个Well-Behavior的存储器。这些谨慎创造了存储器写这个胆小鬼。流水线中执行的存储器读和写指令，其胆量的差别是质的，存储器读指令在没有按序轮到其执行之前已经周游了大千世界，而存储器写指令在执行完毕那一瞬间甚至还没有离开过家门。
在多数现代处理器微架构中，存储器写指令只有在最终Commit之后才能真正向Cache层次结构发送数据。这并不意味着存储器写指令不能Speculative，存储器写在Commit之前也如存储器读一样自由，而且在多数情况下写操作也需要首先读取数据，之后进行数据合并，然后进行真正的写操作。存储器写指令在最后的Commit阶段时异常谨慎，只有在确保一定不会出现问题之后才能提交。这一机制保证了存储器写操作在指令流水线中可以按序完成，也导致了存储器写的延时。
对于一个最终存储器类设备，在流水线中执行的存储器写操作所采用的这种方法依然不能保证到达DDR颗粒或者PCIe设备时，存储器写操作依然会按序到达。一次存储器写操作的轨迹很长，一部分在CPU域中，一部分会在设备域。按序Commit与各类Barrier指令只能保证在CPU域的序。当存储器访问到达其他设备域时，需要遵守其他序规则。这些内容超出了在这里的讨论范围。
我们重新讨论存储器写的延时。正如大家所知，存储器写可以Posted，原本可以较快的执行完毕，只是由于Speculative的原因，存储器写操作很有可能会被错误地提前执行，只是在这条存储器写指令没有Commit之前，都有修改的余地。这个余地带来了写的延时。
这个延时在一个追求极致的微架构中是不能忍受的。最具智慧的一群人在有资格一起进行极限挑战时，差距非常微小。在这些人眼中，处理器的一个Cycle已经被细化为十分之一，甚至百分之一。两个追求极致的CPU，指令平均执行效率如果相差了一个Cycle，意味着这两个CPU本不应该在同一个舞台上竞争。
必须要最大程度地利用这个延时，以提高存储器读的效率。与存储器写相比，存储器读非常幸运。在正常情况下，对于Well-Behavior存储器的某个地址读一千次一万次，也不能将其从0读成1。读操作可以更大胆一些。
存储器读指令获得EA后，首先需要访问的是LSQ，检查是否在尚未Commit的写操作中是否具有数据副本，从而消除了存储器写带来的延时。在LSQ中没有命中时，存储器读指令才会访问Cache层次结构，并将结果放入对应的LSQ等待提交。在访问Cache层次结构时，这些读指令有快有慢，这造成了存储器读的乱序。更为糟糕的是，有些读操作可能不应该被提前执行。虽然这个存储器读的结果可以被指令流水线最终丢弃，但其执行轨迹却无法消除。
这是因为Load/Store Speculation，也引出了数据访问序这些概念。很多系统架构师熟悉这些序，也在有意无意的利用着这些序。下文讲述的这个实例发生在在一个多处理器并行编程系统中。在这个系统中，存在C1和C2这两个CPU，并使用共享存储器进行通信。
C1首先向A1地址写入一个命令，之后将A2地址的数据加1。C2使用存储器读操作获得A2的数据后，首先进行数据检查，发现数据变化后，得知A1中已经存放了新的命令，之后再处理这个命令，其源代码示意如图1‑4所示。
这样的代码在支持Load/Store Speculation的微架构中，有很多问题。一个简单的想法是C2的Load Speculation可能导致Read A1得到的命令并不是最新的。但是C2在何种情况之下才能得到旧的数据，并不是简单说说Load Speculation这样容易。
曾经有一个朋友与我说，买卖股票其实很容易，Just buy low and sell high，But how难住了他。Load Speculation引发灾难的各种可能性也很难用一两句话描述清楚。此处仅以图1‑4说明一个简单的可能出现错误的场景。
假定C1没有出现问题，对A1和A2这两个地址的存储器写访问按序进行。与此同时，C2采用Load Speculation技术以加速存储器读，但是Read A2和Read A1这两个操作最终依然按序完成。只是C2在访问A2时，发生了Cache Miss，经过很长一段时间之后，假设这段延时为m，C2才能获得真正的数据，而Speculative Read A1读取的数据在Cache中命中，C2将其放入LSQ中，等待最后的提交。
如果C2最终从A2中的获得数据没有改变(Check A2)，则重新读取A2重新判断，在LSQ中的A1将被抛弃。Speculative Read A1的结果会被抛弃，并没有什么问题。只有在某个机缘巧合之下，Speculative Read A1的结果才会错误，这个概率非常低。
假设在延时m这个时间段里，C1更新了A1和A2并对于C2按序到达。只是在C1更新A1之前，C2已经进行完成Speculative Read A1，此时C2得到的是A1的一个历史值。C2在延时m内最终获得了A2，这个值已经被C1更新，因此C2将获得更新后的A2，此时分支预测单元将误认为C2的Speculative Read A1的结果正确，不会重新对A1进行访问。此时造成了C2获得了一个最新的A2和旧的A1，引发了一个致命错误。
有很多方法解决这个错误，只需要在Check A2之后，显示加入Barrier类指令，避免Load Speculation，或者直接设置MMU禁止对这段存储器访问的Load Speculation。虽然只有在某个机缘巧合之下，Speculative Read A1的结果才会错误，而且这个概率非常低，但是我们仍然需要保证这段程序在执行过程中100%正确。问题是我们要为不到1%的概率，将如此沉重的Barrier操作强加到99%以上的每一个正确之上。
这个Barrier并非不可移除。只要C2发现Read A1命中Cache之后，将其之前出现的Read Miss读操作加上Snoop Resync Flag的标志。标志为Snoop Resync Flag的读指令在Commit结果时，抛弃其后的读操作，就能避免这些沉重的Barrier操作。在这个例子中，使用这样机制后，Speculative Read A1的结果将被流水线丢弃，之后重新执行，沉重的Barrier操作得以取消。AMD Opteron使用了这种机制[13]，类似的机制也出现在其他现代处理器中。
有心人会从各类处理器的优化手册和这些公司近十年来发表的IP，猜测出这些处理器实现的某些细节，即便这些公司敞帚自珍一些更重要的细节，从不发表这些细节的IP。敞帚自珍总是暂时，时间将冲破任何障碍。美国中央情报局称，早在RSA算法发布之前，他们已经掌握了公钥体制，只是没有公开。他们的孤芳自赏没有改变这个体制的如期而至，只是成就了Rivest，Shamir和Adleman的不世之功，传世之名。
不想继续探讨有关IP的深重话题，但是总有要说的话。IP自有其存在的道理。羊儿有羊儿的道理，狼儿有狼儿的道理。IP以保护知识产权的名义诞生，历史越是悠久的公司，IP的数量也更加多些。在很多时候，我们并不知晓有些IP是如何审批通过。某些行业的某些IP有如“天是蓝的，草是绿的”这样的常识。这些IP不因我们称其无耻而消亡，这些IP的发源地很多是来自某些如雷贯顶的巨型公司。
IP制度最初是为了保护创新，发展至今总能找出其妨碍创新的实例。很多时候真正的创新产生于悲寒交迫饥饿着的人群中，不发生在衣食无忧领取薪水，悠哉游哉喝着咖啡聊着天的白领中。这使得很多历史悠久的公司为真正创新所做出的努力反而不如在车库中工作着的年轻人，这是一个客观存在的事实。
这些年轻人历千辛万苦的成果，却能很轻易地被“天是蓝的，草是绿的”这样的IP拒之门外。深入思考这些问题后剩余是无奈后的反思。天将是蓝的，草依旧是绿的。人类的生存与发展，需要的是不断进取所带来的创新，这是世界大行，是再多的魍魉魑魅，再多的阴谋诡计无法阻挡的。
参考博文：saling的博客 系列专题http://blog.sina.com.cn/s/blog_6472c4cc0102dusv.html