Rocket - tilelink - ProbePicker

Posted wjcdx

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Rocket - tilelink - ProbePicker相关的知识,希望对你有一定的参考价值。

 

 
简单介绍ProbePicker的实现。
 
?技术图片?
 
1. 基本介绍
 
用于把多个Cache client合并成一个:
?技术图片?
 
2. diplomacy node
 
ProbePicker的diplomacy node是一个适配器节点,用于与上下游节点连接,并进行参数传递。
?技术图片?
 
这里下游节点的参数向上游节点传递时不做改变;上游节点的参数向下游节点传递时进行了适配,把可以合并处理的cache client的参数进行了合并,这样下游节点看到的ProbePicker的client参数中就少了一部分被合并掉的client。
 
1) clientFn
 
把原clients中的元素从右向左逐个进行combine,合并后的结果作为新的clients参数:
?技术图片?
 
2) combine
 
这里的假设是连续的client访问的地址集合(visibility)是有序的:
?技术图片?
a. 若head和next有重叠,则不能合并;head的意思是能够合并的元素的头一个,既然不能合并,那么head就失去了其意义,将其加入到output即最终的clients序列中,而下一个元素成为接下来要检查的能够合并的元素的头一个元素,即下一次combine中的head。
b. redact用于把head和next的sourceId/nodePath和visibility忽略掉进行比较,要求其他的域如name/requireFifo/supportsXXX等都需要相同;
c. 合并则是将head和next两个的sourceId和visibility进行合并;
 
3) 合并sourceId
 
head和next的sourceId具有怎么样的关系?
a. 重合:部分重合或者全部重合;
b. 不重合;
 
3. lazy module
 
lazy module用于实现ProbePicker的内部逻辑:
?技术图片?
 
因为diplomacy node中可能把上游节点的多个clients合并到一起了,所以下游节点看到的sourceId实际上也是合并之后的,即下游节点发起Probe消息时,使用的是合并之后的source值。需要ProbePicker把这个source值区分成合并前的某一个client再转发给上游节点。
 
1) 成对的输入边和输出边
 
?技术图片?
 
2) 默认直连
 
?技术图片?
 
3) 区分source
 
?技术图片?
a. edgeIn.client.clients.size是输入边的clients的数量,即ProbePicker看到的上游节点的clients的数量;edgeOut.client.clients.size是输出边的clients的数量,即ProbePicker的下游节点看到的ProbePicker的clients的数量。两者相等,表明没有进行合并;两者不等,则表明进行了合并,则需要对source域进行区分;
 
b. 判断source属于哪一个client:edgeOut.client.clients.map(_.sourceId contains out.b.bits.source)
 
c. 如果合并前只有一个client的sourceId被合并后的client包含,则表明这个client没有与其他client进行合并,所以无需区分;
?技术图片?
 
d. 否则需要根据地址确定是属于哪一个合并前的client(这些client的visibility不重叠),而后转换为对应client的sourceId:
?技术图片?
 

以上是关于Rocket - tilelink - ProbePicker的主要内容,如果未能解决你的问题,请参考以下文章

Rocket - tilelink - Monitor

Rocket - tilelink - ProbePicker

Rocket - tilelink - Edges

Rocket - tilelink - Xbar

Rocket - tilelink - Filter

Rocket - tilelink - Metadata