“浅谈高端CPU Cache Page－Coloring（全）”有34个回复

1. tree 于 2011-06-20 7:38 下午

   沙发？

2. cjk 于 2011-06-20 9:37 下午

   首席大作终于收官了。

3. netmizer 于 2011-06-21 1:21 上午

   路过，楼下的继续！

4. Justdoit 于 2011-06-21 1:29 上午

   首席，这个《全》不怎么全啊，第一部分的两张图就没有。

5. kernelchina 于 2011-06-21 3:39 上午

   首席什么时候点评性能优化系列？

6. 一大杯茶 于 2011-06-21 8:22 上午

   有个问题，Set index bits相同的地址肯定会对应同一个bin的同一个set，就算同一个bin内的其他set有空闲也不能使用吗？

7. 陈怀临 于 2011-06-21 3:58 下午

   Thanks to Justdo it. Fixed now.

8. anonymous 于 2011-06-21 5:27 下午

   能否讲讲cache,内存对齐,channel,rank等之间的关系

9. xux 于 2011-06-21 5:45 下午

   非常感谢首席的文章
   非常感谢首席的整理

   向首席致敬

10. netmizer 于 2011-06-21 10:52 下午

    华为1.5亿美元设印度研发中心
    http://www.people.com.cn/h/2011/0616/c25408-3249866131.html

11. march 于 2011-06-25 10:54 上午

    支持首席。

12. mie~~ 于 2011-06-25 5:52 下午

    居然huawei去印度搞研发中心, 我看丫的是要完蛋了…

    莫非huawei觉得老印写的code比自己的质量还好?

    那华为就真的完蛋了…

    或者哪个领导脑子被驴踢了 ?

13. Puppy 于 2011-06-27 10:17 下午

    好东西

14. 弈梵 于 2011-06-28 8:33 上午

    首席，“有多少人想过，两个512k的数据结构有可能互相残杀？？”这是不是有点不妥？
    在2M 4way的cache中，假设从0地址开始申请两个512k连续地址空间，这两个地址空间是相同的“cache bin”没错，但是这不等于他们会互相残杀啊。
    cache中一个set有4个line，一个512k地址空间将会占据所有set中第1个line，第二个512k地址空间会占据所有set中第二个line，所以两个地址空间不会互相残杀。

    以上是自己理解，有可能是错误的。

15. 谢婧雅 于 2011-08-28 9:05 下午

    陈老师，请教个问题：
    如果Cache做成全相连的，是不是在最坏情况下，从Memory映射到Cache的查找操作，会退化为类似在单链表中顺序查找的过程？当然，芯片内部是并行的，可以以大大增加CPU面积、成本和发热量为代价，来提升这个查找的速度——这也是全相连Cache不实际的原因。您觉得我这样的想法对吗？

16. 陈怀临 于 2011-08-28 9:32 下午

    小谢同学，uuuuum，很好的问题呀。。。请问在哪里上学呀？：－）。我这个Cache Page Coloring的文章略微有点少儿不宜 or／and 女同学不方便。。。

17. 一条虫 于 2011-08-28 9:56 下午

    首席明显低估现在的少儿了。。

18. 缓存一致性非常非常难 于 2011-08-28 10:03 下午

    Fully associative cache 无法实现，或者说实现的代价太大，而且，fully associative相对于16way的性能提高几乎没有。

19. 谢婧雅 于 2011-08-28 10:11 下午

    有的时候如果coloringing没有做好，会造成若干页memory，共同映射到一片cache里面，这样就只能排队用cache，也就是造成cache ping pong，严重影响系统效率。
    这让我想到了，在李敖写的一本讲台军生活的书里面，有这样的描述，台军士兵拿着发的福利券去找军妓，排队的时候，后面的士兵猴急地催前面的，前面的越催越慢，不啻是一道美妙的军营风景线。

20. 谢婧雅 于 2011-08-28 10:14 下午

    TO 18:
    也就是说，xxx way cache是一个折中的方案，用有限的成本(包括面积，费用，功耗等)提升，来换取cache命中率的大大提升，对吗？
    那么，如何评估cache”利害变换线”的way数目呢？

21. kevin 于 2011-08-28 11:41 下午

    you can get some data from
    see mips run
    or
    Computer Architecture: A Quantitative Approach

22. 谢婧雅 于 2011-08-28 11:45 下午

    SEE MIPS RUN的Cache部分一直没怎么看懂…… #^_^#

23. kevin 于 2011-08-29 12:21 上午

    according to mips, 4way ~= full associative. random ~= LRU

24. 陈怀临 于 2011-08-29 6:59 上午

    See MIPS Run的cache部分没看懂，那就有点不应该了。阿雅，要补补基础课。是不是你们学校的老师有点问题？

25. 缓存一致性非常非常难 于 2011-08-29 8:12 上午

    set associative缓存具体是多少way，不是设计师的选择，而是集成电路工艺决定的。在一定的速度要求下，能够比较多少位的地址，就实现多少way。

    从8 way到16way有可见的提高，但是模拟实验表明，从16way到32way，提高几乎没有。大概一百万次访问里面，32way可以减少个位数的缓存失误。

26. kevint 于 2011-08-29 11:07 上午

    you can get data from
    http://www-mount.ece.umn.edu/~jjyi/prof_links/L1_D-Cache_Miss_Rates.pdf

    it is clear that at 32kb level which is a common size for L1 cache there is little difference between 4way and 8 way. For larger cache the difference is neglectable. So “从8 way到16way有可见的提高” is not that true.

    anyway the test is under single thread processor, more ways should help under multiple thread processor. a few server chip got 16way cache.

27. 缓存一致性非常非常难 于 2011-08-30 4:24 上午

    如果你不去亲自做实验，你无法推翻这个结论。

28. sailing 于 2011-08-30 7:46 上午

    1. 8:1 the rule of thumb of John and David

    2. Cache越大越慢

    3. Way越多，decode时间越长

29. 缓存一致性非常非常难 于 2011-08-31 6:25 上午

    那些似是而非的结论是有害的。

    缓存可以用10级流水线，再大几倍都没有问题。

    way的比较根本不是问题。

30. kevint 于 2011-08-31 10:20 上午

    大家讨论的不是一个东西。L1不可能搞10几级流水线。L2就无所谓了。我也相信在mc，mt的场景way越多越好。

31. sailing 于 2011-08-31 6:12 下午

    Way有多少，不是某一级Cache单独能够决定的。有的时候是设计的不得已。
    简单的例子。
    在L1 Cache层面。首先存储器读与写关心的重点不同。读关心Load-Use Latency，而写要关注Bus Traffic。一般说来现代微架构的Load-Use Latency在3~5之间。AMD从K8开始这个Latency为3，最新的Bulldozer的Latency为4，不是最新的不好，而是为了扩大带宽。Intel的Nehalem和Sandy Bridge是4，T4是5.
    L1 Cache Pipeline不会太长，实际上L1 Pipeline中处理的内容较为固定，分Hit和Miss两种情况讨论。3~5 Cycle指Hit，Miss后多些节拍，好在都是Non-Blocking的。Hit分为AGU，Decode，Access，还有一个是L1 TLB(Virtual Cache不用)，有四拍组成。
    其他的不说了，Decode指N-Way search and find Hit的过程。
    如果微架构的主频为3.3GHz，那个一个Cycle是300ps，做不了太多事情的，L1 Cache在我视线所及甚至没有超过8way的，其中Decode比较是个大问题，有机会大家可以用FPGA写段Verilog程序验证一下一个CAM在不同Entry下的延时就知道了。CAM条目越多，译码时间越大。频率稍高一点点，就无法满足设计要求了。
    而L2 Cache的Way要看和L1 Cache的关系，是Inclusive，Exclusive或者NI/NE，不能一概而论。有些Cache的Way很长，比如16或者32，很多都是实现中的不得已，并不是单独考虑多几个Way，Hit Rate更高些，更多考虑的因素是相互间的Inclusive关系。
    多级Cache使用的Coherence Protocal和Memory consistency超出越大多数没有真正做过这些设计人的想象，这是一个尚未解决的State-Explosion问题。仅是部分验证需要上万台服务器跑几个月。其中的State，Corner和Race Condition在4级Cache层次结构中太多，以至于上千万条Trace验证后，大家都不知道自己做的是不是一定正确。

    进一步考虑Hit/Write policy，replacement, Speculation等一系列因素，Cache设计更为复杂。

    上文列出的三个结论出自John和David的A Quantitative Approach。从宏观的角度上看，这些是考虑了千千万万因素之后，凝结后的几句话。John和David的量化分析是春秋笔法的，因为这两个人知道的东西太多，知道有些东西根本没有办法写，知道有些东西先给入门者一个直观模糊的概念更重要。

32. tek 于 2013-03-11 9:16 下午

    “如果系统还是我们文章中例子的2M Cache。其x是18.
    (18-18+1)=1.
    这意味这什么？ 这意味着，一个2M的cache在OS或者应用程序的512K的页面分配机制
    下，cache其实就是被拆成了两个Bin。（2^1=2)”

    512KB的页面，2MB大小的cache，4-Way, 如果得出是两个Bin?

33. pzz2011 于 2014-04-03 8:18 上午

    如何可以在写一篇（最最简单的）程序从磁盘加载开始…到执行第一条指令的（和cache，mmu，tlb联系在一起）文章就好了.
    反正我是很混乱，不知道到底有多少人懂得呢？

    或者说我这么考虑问题，想要了解的东西是不对的呢…

34. lucia 于 2014-04-11 11:22 上午

    搞个uboot，bootcode看完就明白了就那么点东西