同学，你好！
感谢你对香山处理器的关注和建议！ 我们正在开发适用于香山的 private L2 cache，为了提高频率我们会除去 ListBuffer 的设计，并针对预取做一些优化，我们阅读了你的毕设论文，其中优化简单请求处理路径的 SCU 模块、一体式请求缓冲和请求发射思路对我们很有启发，欢迎和我们继续交流。 不过香山-雁栖湖目前所引用的 SiFive 开源的 InclusiveCache 的 Set 碰撞处理机制和论文中描述的版本还稍有不同：在雁栖湖这个版本里的 SiFive InclusiveCache 中，ListBuffer 的入口数等于 MSHR 的数量，即每个 MSHR 对应一个链表。不过 MSHR 与对应的链表依然是同 set 的关系，所以在 ListBuffer 用 SRAM 存储链表头节点的背景下，用 MSHR 编号还是 MSHR 的 set 值来访问链表差别并不大。 ListBuffer 高开销的链表设计是为了实现动态长度，充分利用存储资源，避免总线端口阻塞，这一点通过类似你论文中的一体式的请求缓冲应该也能够达成，但可能也会引入新的性能和调度/唤醒逻辑开销上的权衡。 SiFive InclusiveCache 中 MSHR 在完成请求处理后也是优先从 ListBuffer 取出同 set 的请求继续处理的（在代码中叫做 reload），这点我觉得跟论文中的分配编号和请求计数器的思路是比较相近的。 但抛开 ListBuffer 的链表开销不谈，SiFive InclusiveCache 为了追求被调度的 MSHR 在下周期立即开始处理同 set 请求，会同周期直接将经过复杂的调度逻辑选出的 MSHR 编号送进 ListBuffer 中取出同 set 请求，已经具有非常严重的组合延迟。 如何在同 set 串行执行的前提下平衡 MSHR 利用率和调度逻辑复杂度，也是我们设计香山自己的 L2 cache 时所需要关注的重点之一，希望能够继续交流讨论。 祝好 王诲喆 -----原始邮件----- 发件人:Ausar <464270...@qq.com> 发送时间:2021-07-09 15:07:27 (星期五) 收件人: xiangshan-all <xiangshan-all@ict.ac.cn> 抄送: 主题: 关于LLC调度方面优化的一些建议 老师、学长好，我是计算所准研一学生陆俊峰。 正在阅读香山处理器的相关文档，发现你们对于LLC进行优化的时候，为了解决ListBuffer这个硬件链表的开销，把这个缓冲队列砍成了只有一级缓冲，可能导致潜在的性能损失。 我的毕业设计是设计一个多核共享高速缓存，其中对于这一部分内容的解决方案是采用基于编号分配的调度方案。 即: 1.为请求分配一个对应Set的MSHR 2.发射请求的时候直接按照分配的编号进行发射 3.MSHR中维护一个等待中的请求计数器，当计数器为0才允许更换Set 也许这样的调度方案对你们优化LLC有一定的帮助 论文见附件 我微信号是18878878761，希望能和学长们继续交流CPU核相关的知识
