GEM5 GARNET DVFS论文阅读 Part 1：Thread Voting DVFS for Manycore NoCs

简介

关于下面这篇文章的笔记和对应的博士论文的笔记：
Z. Lu and Y. Yao, “Thread Voting DVFS for Manycore NoCs,” in IEEE Transactions on Computers, vol. 67, no. 10, pp. 1506-1524, 1 Oct. 2018, doi: 10.1109/TC.2018.2827039.

Y. Yao phd thesis “Power and Performance Optimization for Network-on-Chip based Many-Core Processors”, 主要是chapter 2 Performance characteristics based NoC power management
.

一些技术背景： alpha架构(在当年合适，现在2023年 arm risc v和x86比较流行)，ruby的 MOESI一致协议，mesh noc，x-y routing防死锁，私有的l1 共享的l2和noc上的mem controler。

Power over/under provisioning scenarios

核心是讲述一般来说，路由器占用率越高，路由器的dvfs越应该设为高频率。 但是在应用/线程级别，有时候这种策略是会造成过度供应或供应不够。

Power over provisioning.

在有的情况下，虽然流量模式在突出显示的路由器列中形成热点，但一旦缓冲区负载变高，增加路由器的 V/F 级别可能并不总是合适的，因为核心可以容忍部分网络延迟而不损失性能。 然而，在基于缓冲负载的DVFS中，如果把路由器的频率将由于热点流量而大幅增加，但性能改进可能非常有限。

这种情况是什么呢：本身下图的hotspot traffic，就应该用高的v/f。

文章提出，“假设核心 1、2、…、7、8 定期向同一 L2 缓存组 A 内的不同数据块发出写请求（这种收集流量模式经常发生在一个 L2 缓存组的不同分区的矩阵乘法）。 进一步假设写请求都是独占的并且没有数据共享线程。 在这种情况下，发出核可以利用写入缓冲器来隐藏写入未命中延迟，并且可以放宽请求的返回时间。”
也就是说，虽然 l2缓存 A那堆蓝线 看上去很拥堵，但是慢就慢点也没事，没必要DVFS提高router频率，提高了也没啥提升。如果按照常规的方法，bufferload提高就猛提频率，(有可能)徒增功耗罢了。

Power under provisioning.

大概就是有的时候NoC网络看上去不拥堵，但是其实在线程角度看来，得猛猛冲。

“如图 2.1b 所示，假设核心 1、2、…、7、8 分别定期向 L2 缓存组 A、B、…、G、H 发出写请求。 进一步假设每个发出线程都有多个数据共享线程（这种流量经常发生在例如多个线程竞争锁定共享变量时）。 为了保持内存一致性，数据共享线程向同一数据地址发出的连续请求被禁止返回新写入的值，直到所有复制的高速缓存副本都确认收到无效或更新消息。 在这种情况下，即使流量模式分散并且每个经过的路由器可能具有较轻的缓冲区负载，但降低路由器的V/F级别可能并不合适，因为正在进行的写请求的完成时间会影响发出和数据-共享线程的进度。 在基于路由器缓冲区负载的DVFS中，图2.1b中通过路由器的频率将由于低缓冲区负载而被不适当地降低，这可能会为了有限的节能增益而牺牲相当大的应用性能。“

说人话就是NoC这时候不忙，但大家都在写一个值，比如就叫Coherence_Value_1, 他本来是在memory里的，现在在caches ABGH 四个 L2 caches里了，Core 1通过NI1 再通过一串router现在要写 l2 cach A的值，发了一个包在noc 里慢慢跑。

这个包我们叫packet_1ToA 好了，假设网络很空，只有4个包 分别是packet_1ToA ， packet_2ToB，packet_7ToG ，packet_8ToH。他们都是和mem里的Coherence_Value_1有关， 而且现在4个l2 caches里都有这个值在用。 本来是router可以低频率的，因为在noc角度看 router 很空。但是如果按常规 router低频率运行的时候，packet_1ToA在noc里慢慢跑，但因为缓存一致性的要求，packet_2ToB，packet_7ToG ，packet_8ToH三个包被拦住不让动，性能就很受影响里。

这时候NoC里的router也很无辜，我只知道buffer低就降低频率，buffer低就提高频率，你的data dependancy我一个路由器哪里顾的过来呢。
所以文章就说，那我们即使对于router的DVFS，也看看线程的信息吧: 这就到了 "Thread Voting DVFS for Manycore NoCs“ 的 thread voting 了。

DVFS tuning granularity

简单的说就是文章认为每个路由器都调不合适，但是所有router一起调节看着也很粗暴合适，就分区域调节了。

Per-thread characterization using the (γ, s) model

分区域的话，假定我有四个router A B C D，A BC 需要高 D 需要低 频率，咋办呢？ 那就投票了。少数服从多数。

不过怎么知道需要高还是低呢？

The ( gamma , s) model.

*“ gamma 是捕获每个时期未命中状态保持寄存器 (MSHR) 中未完成的 L1/L2 未命中的平均数量的消息生成率，s 是每个时期每个数据请求的数据共享者的平均数量，作为线程的通信特征参数。 由于核的L1/L2未命中必须封装成数据包并通过网络转发到相应的L2或DRAM，因此 gamma表示线程的平均网络访问强度。 此外，s 反映了线程的数据请求相对于其他数据共享器线程的重要性。 线程拥有的数据共享者越多，线程的数据请求可能变得越关键，因为请求的完成时间可能会影响数据共享线程的进度。”

gamma是 caches missiing的次数代表里需要访问NoC的次数，L1 caches missing 需要去L2，L2 missing需要去 最顶端和最底部的mem nodes。 (但是这里有个问题，l1即使没miss，也要传包给其他l2 caches和 memnode来保证一致性。 虽然所有的数据更改都有这个包，也许忽略是合理的。 但这里没有讨论它的占比，就直接忽略了这个问题。)

s是数据共享者的数量，s越大(某种程度上）说明这个值越重要，可能很多线程都在等这个值。

控制策略

策略是一个简单的表。也可以叫fuzzy controller：

s是数据共享者的数量，上文说了 s越大(某种程度上）说明这个值越重要，所以S high的时候，就用 conf.A ， 除非网络太空了的时候用conf.b。
s中的时候，还是至少给conf.b,不管网络怎么样。
s低的时候，网络不管拥堵与否，都只给conf.b 和低的时候给conf.c。
而读的时候，不涉及缓存一致性带来的数据依赖，所以无所谓。

这里有几个思考：

1. confB某种意义上是基准，需要boost的时候提升频率到confA，不需要的时候降低到confC，但是如果confB预设的不够好呢？

比如下图，我们希望按左上角的ABC排列。提高到A ，router的 peformance和V/F level （以及背后的功耗）都提升，降低到C 的时候 都下降。 (在这之后，才是router的高表现是否导致线程级的高表现问题)

举个表现差的情况，如果confB取到了A 或在C的位置，那么基于此位置的 confA 或者confC 效果就会很差。

小结就是，预设的三个conf需要技巧， 设置为什么值也影响很大。

Router 和 NI 的设计：

在L1 missing 以后，来一个 message作为payload，给这个message加个vote。header就变成了 addr /vote/payload.

这个vote,在实现细节上还加了一些滑窗。

DVFS的调节

RDC 调控DVFS 信号的传递

从下图可以看出来，vote是随包出来的，流过哪个router就更新一下投票器，然后RDC 再分别调控DVFS。。

但是有个问题就是，DVFS 是如何传递控制消息的呢？

下图更清晰一些，可以看到Region DVFS Settings Logic并没有用noc传递信息，而是"虚空"就完成里对四个Router的设置。 如果在具体的电路上，则是有k=4 根单独的信号线专门用来走这一个控制信号： 5个 router的vote信息是直连RDC 的，然后5个router也是直接接受里RDC的控制信号来调节V/F level。

VOTE的细节

VOTE 的阈值

原理上大概是少数服从多数，细节上有则分为两个阈值，如下图：三个颜色各有三个值，分别是投票的数目。

1. 特别低的，低于theta_1的，直接忽略不计。这样可以避免菜鸡互啄，大家对某个v/F level 的意愿都很低， 那就别变。
2. 投票差距大到一定程度的时候才改变。比如红的a减去绿的c，和theta_2相比，如果相差比较大，说明投票的意愿比较强，需要调整为 high V/F。也就是说没把握就别乱动。

### VOTE 的机票

每个router过一个packet (原文用的packet。但packet其实是有些不合理的，因为router并不会把flits存一起，deflitize后特意看一眼header再flitize回去。根据上下文推测是用的header flit，所以语文上用packet也没问题) 就给经过的packet加一次count。如果x-yrouting后，一个headerflit 会经过 2x2 routers个中的 3个routers，那就是三票。

这个加强了某个需要改变VF level的 header flit， 对它主要通过区域的影响力。 但想了想， 2x2 的router在x-yrouting下，只要经过就至少是2个router，最多是4个，估计大部分也就是 2票。不知道这个2票3票4票的票数分布是怎么样，有没有必要计票。

一些实验细节

实验设置

gem5里仿真的细节：
processor 是alpha 2G 乱序的。 L1是32kb。L2是64X1MB, 全chip共享。
NoC是8x8, 6 VC，每个VC buffer depth 是4个flits。 128bit的link bandwidth。一个cache block是8个flits。 缓存一致协议的包则花一个flit。
DVFS 则是 3个level，1.5GHz， 1.75GHz， 2.0Ghz。电压在gem5里基本就是个挂在频率上的数字而已。

实验结果

结果就是，shared data少的时候，TVD用的频率低(功耗)，但是效果略差。比如图A 总是高频率，图b总是低频率。下图是 swaptions的，文章还宣称 facesim, fluidanimate, streamcluster, and vips也有类似的效果。
这个时候，就是over provisioning了，而tvd可以不over provisioning的同时，效果降低不多。

对bodytrack dedup and freqmine.BLD就用低频率，然后文章说应该用高频率，下图是bodytrack的，因为有很多shared data,也就是缓存一致性需要更多的考虑。
但是图c的坐标变了，也就是展示的核和上图不一样，而且也没什么规则，为什么是这8个cores？ 也许是为了present most significant results？

上面两个图里的perf是 system-level ROI finish time .

如果放在全部parsec里，则是下图：实际上的提升是under provesion group，相比BLD的 10%左右。

对于OP的部分，很显然时间上是没有提升的–因为BLD用过度的电压频率换取里更短的时间。不过TVD 就可以对比一下功耗了：

上图可以看出，中间的op group， 浅蓝色的tvd功耗更低。 而在up group中，上上图的时间里TVD要短于BLD，代价就是上图中的功耗要高。

结果看到这里就够了，还有一些细节的MIPJ和spec benchmark的结果，简略读读的情况下看多了反而会读杂了。

小结

TVD把parsec分成里三组，non-op op 和up。 TVD文章提出的方法（thread voting)和BLD相比， 在op组时间稍慢但是功耗降的多，在up组功耗多但是时间比BLD快。