浅谈高端CPU Cache Page-Coloring（6）

作者 | 2011-05-30 22:58 | 类型 专题分析, 芯片技术 | 20条用户评论 »

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




系列目录 高端CPU Cache Page Coloring

  1. 浅谈高端CPU Cache Page-Coloring（1）
  2. 浅谈高端CPU Cache Page-Coloring（2）
  3. 浅谈高端CPU Cache Page-Coloring（3）
  4. 浅谈高端CPU Cache Page-Coloring（4）
  5. 浅谈高端CPU Cache Page-Coloring（5）
  6. 浅谈高端CPU Cache Page-Coloring（6）

前面5节阐述了大CPU大Cache的Cache Page-Coloring的一些基本概念。主要是通过妈咪的包厢运作制度来作为各位弟兄们比较熟悉的场景，从而达到融会贯通的。

在Cache Page-Coloring方面，一个前提是“里面放了N个长凳子的包厢制度”–Set Associative的Cache。否则，一切无从谈起。

这一节谈一下目前大CPU中的L3 Cache的一些问题。通常我们说LLC–Last Layer Cache。

目前市场上不少芯片都有了On-Die的L3 cache，例如Intel的Nehalem-EX, Westmere，IBM的Power7，RMI的XLP，Tilera等等。

与L1和L2的Cache相比，L3 cache的设计和管理方式有相同的地方，也有不一样的地方。

这里比较容易犯迷惑。

1。L3也是Set／Associative的。换言之，学术界和工业界没有，也没有傻到整一个新的Cache机制。从而，Page Coloring的各种思想和算法是而且当然是可以apply到L3 cache中去的。
2。 与L1，L2 cache controller相比，L3的实现是各个厂商差别很大。各有千秋。但总体而言，都是通过一个Distributed L3 Cache的机制，在系统层面提供一个完整的Set／Associative的L3 Cache。其中用Ring结构的还是比较多，例如Intel，RMI等等。Tilera用是其声称的Mesh结构。

3。对L3 cache理解里最容易出错误的就是这个通常不是Local bus的Interconnect结构，例如Ring。从而对其寻址方式和其结构方式造成混淆。请记住：Local Bus的直接拿Index bit来寻址和通过Pa做Hash来寻址，这是一个微结构的事情（Micro－Arch），而非结构（Arch）的事情。在结构上，L3仍然是一个Set／Associate的Cache。例如Nehalem－EX（Beckton）的24M的24Way的L3 Cache。这就说明，这个L3 Cache有(24＊2^20)/(24 * 2^6) = 2^14=64K Sets.
[Nehalem的Cache Line是64Bytes]。

显然，通过我们上述几节的分析，在Intel CPU上，一个44位物理地址的0－5是cache offset；6－19是Set的Index bit。我们会在后续文章中对Intel的L3 Cache的微结构做一些探讨，例如其hash机制。

下面是一些相关CPU（Nehalem－EX；XLP－832
，Tilera和Power7）的L3 Cache结构示意图：



系列前一篇
(2个打分， 平均：4.00 / 5)

工具箱
本文链接 | | 打印此页 | 20条用户评论 »

雁过留声

“浅谈高端CPU Cache Page-Coloring（6）”有20个回复

  1. xux 于 2011-05-31 1:57 上午

    sf? 标记。
    目前模模乎乎看，不是很懂。

  2. kernelchina 于 2011-05-31 2:19 上午

    在XLP的那个图里面，8个bank是什么意思？可以并行的8个内存访问？如果所有的core同时访问一个bank怎么办？

  3. Sting 于 2011-05-31 2:36 上午

    起个头就结束了。。。。强烈要求尽快更新

  4. tacas 于 2011-05-31 2:57 上午

    估计看了这个之后，Panabit的性能又会提高不少啊。

  5. 理客 于 2011-05-31 5:26 上午

    看来要用cache assoicated的方法提高系统性能太难了，没有金刚钻，不能揽cache的活

  6. 奔三L2缓存512KB 于 2011-05-31 9:57 上午

    回答2楼：

    8个Bank就是8个独立的缓存，各映射地址的一部分。

    高级的缓存都是流水线，不怕8个CPUcore的同时访问。

    缓存的流水线有10级，比CPU核心复杂。

    CPU核心本身简单，主要是软件生态环境的门槛。

  7. 纳闷儿 于 2011-05-31 8:23 下午

    请教首席及各位高手.

    我在实际工作中遇到一个跟cpu有关的问题.
    intel 5506 cpu 升级到 intel 5606后性能显著下降(近一半). 仅更换cpu, 其他一硬件\软件都未改动.
    程序中没有针对cpu的设置.
    可能是什么原因造成的呢?

  8. 纳闷儿 于 2011-05-31 8:26 下午

    再问个傻问题：
    5606 缓存8M， 5506 4M
    价格却差不多， 是因为工艺提高后成本下降了？

  9. 陈怀临 于 2011-05-31 9:34 下午

    理论上，你的statement不可能为TRUE。Westmere的Nehalem的Shrink否则白做了。

    能否在Linux下做一个 /proc/cpuinfo。确保HyperThreading开启了。

  10. 陈怀临 于 2011-05-31 9:35 下午

    32nm下大量量产应该是原因之一。但定价的原因往往很复杂。。。不是单纯的成本原因。

  11. multithreaded 于 2011-05-31 10:11 下午

    碰到过。 原因很复杂，主要是软件要重新编译，尤其是库函数。

  12. 纳闷儿 于 2011-05-31 10:26 下午

    谢谢首席答复！

    超线程都没有开
    将进程与特定cpu core 绑定后，效果有了很大改善， 两种cpu应该差不多了(还在对比中，没有最后数据)

    现在的现象：
    绑定， 效果差不多。
    不绑定， 低端的5506好很多。

    操作系统对5606支持不够好？ 还有什么动作可以尝试一下？

  13. 纳闷儿 于 2011-05-31 10:31 下午

    to: multithreaded

    重新编译需要在5606的环境下进行？
    库函数是指软件的库？还是系统的库函数？

    谢了

  14. multithreaded 于 2011-06-01 10:59 下午

    重新编译需要在5606的环境下进行, 最好用新版 的GCC（4.4+），库函数是指glibc的库, 要和5606匹配。

  15. 胡不才 于 2011-06-04 10:11 上午

    只换CPU，不换主板和内存？内存上，5506只是800Mhz，5606可以用上到1033Mhz，至少在这里就有提高。

  16. Lucifer 于 2011-06-05 1:17 上午

    5506和5606都没有超线程啦，很好认，非0结尾的都没有

    定价的问题，同定位的定价通常是接近的，工艺进步，赛的晶体管自然变多了

    westmere在指令集方面就多了个avx，应该变化不大，性能方面最有可能影响的大概是主板bios没做好，对新cpu支持不佳，我猜的

    微架构方面westmere跟nehalem相比变化不大，编译方面应该没啥不同，至少跑spec cpu是没区别

  17. Lucifer 于 2011-06-05 1:19 上午

    ～ ～上面的avx是aes的手误

  18. Lucifer 于 2011-06-05 1:27 上午

    还有，编译是不需要在对应平台的吧，指定目标架构、指令集版本之类的就好了

  19. dongbinghua 于 2011-10-11 9:07 上午

    LLC–Last Level Cache,

  20. dongbinghua 于 2011-10-11 9:13 上午

    2^14=16K Sets