听说8E2的CPU cluster，all core use shared L2 cache，这个desigb很有想法，这让我想到了HPCA25的一个paper，IBM的latera cache persistence algorithm，每个 L2 在eviction （替换）时，会把被换出的cache line通过ring bus“latera”（横向）write到最空闲或最少活动的 L2 里（这是“虚拟 L3”的实现原理：把原本要逐层写到大 L3 的数据转而写到某个在同作用域的 L2）。
在server层面同理：若在本芯片 L2 都无法容纳了，就把该行再“横向”写到另一个芯片上最空闲 L2（对应 vL4 作用域）。这样数据在 cache line 的生存期中会多次“lateral move”（横向移动），直到最终write back memory。
这样就让各个 L2 协同，像一个共用大缓存一样工作，无需真正构建巨大的统一物理 L3 / L4，还可以在配置更改、技术演进、芯片数量/server数量变动时灵活适配。
我们来看原理
基本原理
1.依赖活动计数器跟踪每个缓存单元（片内：8 个 L2；机柜内：8 片芯片）的安装/驱逐事件；时选取最低计数器的单元作为溢出目标（即 LRU 范围扩展）；
2. miss时选取最低计数器的单元作为溢出目标（即 LRU 范围扩展）；
3.溢出事件分级触发：
（1）Primary Castout (PCO)：本地 L2 → 目标 L2；
（2）Secondary Castout (SCO)：若目标 L2 再驱逐，则流向最低活动芯片的 L2；
（3）Tertiary Castout (TCO)：最终写回对应内存端口或失效。
该机制将 L2 作为多级“Victim Cache”，在片内/机柜内构建虚拟 L3/L4，镜像传统包容性层级行为，又充分利用所有 L2 资源
自适应插入策略当应用工作集能驻留本地 L2 时，单一缓存计数器失衡会导致重复溢出并驱逐自身常用数据；引入中间 LRU插入：横向溢出行插入至行内第 1/n MRU 位置，而非最 MRU；若检测到溢出内容占满该插槽，则切换为 MRU 安装，以支持小工作集。
为什么会这样？因为传统的设计当你在L1 miss了，你就得snoop to L2，L2再miss你得上L3，SLC，隔壁L2/L3，DRAM。这样会产生 long latency，并且产生更多的energy waste。所以，我们可以让临近的不怎么用的shared L2/3 cache block当virtual L3/4。可以在一些high cache stress上获得+9-11% performance。
但是这么做，这是有代价的，IBM有好像17种L2 cache state，并且核心一多coherency直接裂开，想想每次L2 miss就要给所有L2发snoop……hhh，snoop满天飞。并且必然要解决你放data的时候别的L2 cache不忙，你读data的时候人家开始忙了的问题。