CN1328670C - 目录协议对多处理器结点内脏数据共享的支持方法 - Google Patents
目录协议对多处理器结点内脏数据共享的支持方法 Download PDFInfo
- Publication number
- CN1328670C CN1328670C CNB2005100313952A CN200510031395A CN1328670C CN 1328670 C CN1328670 C CN 1328670C CN B2005100313952 A CNB2005100313952 A CN B2005100313952A CN 200510031395 A CN200510031395 A CN 200510031395A CN 1328670 C CN1328670 C CN 1328670C
- Authority
- CN
- China
- Prior art keywords
- request
- wsrm
- node
- conflict
- unsettled
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Memory System Of A Hierarchy Structure (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种目录协议对多处理器结点内脏数据共享的支持方法,目的是在采用监听-目录两层协议方式的基于SMP的CC-NUMA系统中,解决对脏状态的数据共享后带来的拥有者不确定问题,实现结点内数据的提前共享。技术方案是在结点控制器NC的硬件逻辑中设计WSRM请求产生逻辑,由WSRM请求产生逻辑监听总线,当监听到总线上出现脏命中且请求的类型为READ_SH时,NC接收总线上的脏副本,产生一个可以对目录块进行操作的WSRM请求,由Home结点所在的NC对WSRM请求进行相应的处理,将最新副本写回存储器。本发明实现了未写回存储器的最新数据在结点内的多个处理器中的提前共享,解决了拥有者不确定问题。
Description
技术领域:
本发明涉及CC-NUMA(Cache Coherent-Non Uniform Memory Access支持Cache一致性协议的非均匀存储访问的分布式共享存储系统结构)系统中数据共享方法,尤其是支持结点内多CPU通过总线监听方式构造CC-NUMA系统中基于目录的Cache一致性协议对数据共享的实现方法。
背景技术:
目前基于SMP(Symmetrical Multi-Processing)的CC-NUMA系统的一致性协议大部分采用单层目录协议,比如SGI的Origin 2000。该类协议一般通过通信辅助部件(Communication Assist)查找对应的目录项信息来进行一致性处理,实现结点内数据的共享。这种实现方法虽然简单,但严重牺牲了结点内Cache与Cache之间数据共享的潜在优势,无法充分利用结点内的资源。基于SMP的CC-NUMA系统的另一种比较常见的实现方法是采用两层协议方式,结点间采用一层协议,结点内也采用一层协议,两层协议的类型可以相同也可以不同。一种常用的结构是结点内采用监听协议,结点间采用目录协议,这种协议方式的优势在于:
1.实现了结点内高速缓存与高速缓存之间数据的共享;
2.结点内的通信代价更低;
3.能够充分挖掘数据的空间局部性和时间局部性,使得请求尽量在结点内得到处理,减少对远程结点的访问次数;
4.能够合并结点内的请求,减少网络上数据的通信量;
5.能利用层次封装的优势;
在监听-目录两层协议系统中,监听协议是指MSI(Modified,Shared,Invalid)协议,处理器流出的请求包括共享读(READ_SH)、独占读(READ_OWN)、写更新(UPGRADE)和写回(WB)请求。各请求的产生情况是:处理器在出现读失效的情况下产生READ_SH请求;写失效的情况下产生READ_OWN请求;UPGRADE请求是由拥有共享态数据块的处理器发出的获得数据块所有权的请求;WB请求用于将Cache块数据写回存储器。
采用监听-目录两层协议方式的系统对以上各种请求的处理与单层目录协议的不同之处在于:
(1)目录块处于专有状态时对READ_OWN请求的处理
采用监听-目录两层协议方式的系统对READ_OWN请求的处理过程是:请求方处理器流出READ_OWN请求,结点内的其它处理器监听总线,如果某处理器有脏副本,就由拥有脏副本的处理器流出带数据的响应,该处理器的状态变为无效,请求方处理器接收响应并将处理器的状态由无效变为脏。该请求在结点内完成,整个处理过程由监听协议独立完成,不需要修改目录块。如果结点内其它处理器不存在脏副本,就将请求发送给Home结点,其处理方式和单层目录协议的相同。
(2)目录块处于专有状态时对READ_SH请求的处理
当目录块处于专有状态时,监听-目录两层协议方式的系统对READ_SH请求的处理方式为:如果没有监听到脏副本,其处理方式和单层目录协议的相同。否则,就要使用监听协议来进行一致性处理。对READ_SH请求的处理流程是:拥有脏副本的处理器流出数据,对应Cache块的状态由脏变为无效,请求方处理器接收数据并将Cache块的状态由无效变为共享(结点内唯一的数据副本,且最新的数据没有写回存储器)。此时目录块的状态仍为专有,如果不采取有效的机制将脏副本写回存储器并修改目录块的状态就会出现一致性协议的失效。因为如果接下来再有外部或内部结点对该块数据发生读写请求时,就会出现拥有者不确定的问题(因为拥有该Cache块最新数据的处理器的状态为共享,而处理器只有在脏状态时才能流出数据),导致系统内一致性协议的失效。目前还没有公开的资料来解决这个技术问题。如何在监听-目录两层协议方式的系统中实现正确、有效的数据共享,是长期困绕人们的难点问题。
在一致性协议的实现时会用到下列定义:
MSI的监听协议中,Cache块可能出现的状态有:
●无效(Invalid):该处理器的Cache块没有此块的拷贝。
●共享(Shared):多个处理器的Cache块有该块数据的拷贝。
●脏(Modified):只有一个处理器有此块数据的拷贝,该处理器称为此块的拥有者。
目录协议中,目录块可能出现的状态有:
●未缓冲(Dir_Unowned):所有处理器的Cache块都没有此块的拷贝。
●共享(Dir_Shared):在一个或多个处理器上具有此块数据的拷贝,且在主存中的值是最新值。
●专有(Dir_Private):仅在一个处理器有此块数据的拷贝,且已对此块进行了写操作,而主存的拷贝仍是旧的。这个处理器结点称为此块的拥有者。
●忙(Dir_Busy):表明目录正在处理有关该数据块的请求,不能马上处理现在的请求。
对于一个给定的高速缓存或存储器块:
Home结点:包含了该块的主存储器所在的结点。
脏结点:其高速缓存中有块的副本并处于专有状态的结点。一个块的Home结点和脏结点可能是一个。
脏副本:处于脏状态的Cache块数据。只有Cache块中拥有数据块的最新值,存储器中的数据是旧的。
拥有者结点:某个处理器保持块的有效副本,在需要时能够提供数据的结点。在目录协议中可能是Home结点或脏结点。
请求结点:发出对块请求的处理器所在的结点。
发明内容:
本发明所要解决的技术问题是:在采用监听-目录两层协议方式的基于SMP的CC-NUMA系统中,避免对脏状态的数据共享后带来的拥有者不确定情况,实现结点内数据的提前共享。
本发明的技术方案是:在目录协议的基础上,在结点控制器NC的硬件逻辑中设计WSRM(Write to Shared for Read Modified Cacheline)请求产生逻辑,由WSRM请求产生逻辑监听总线,当监听到总线上出现脏命中且请求的类型为READ_SH时,NC接收总线上的脏副本,产生一个可以对目录块进行操作的WSRM请求,由Home结点所在的NC对WSRM请求进行相应的处理,将最新副本写回存储器,实现未写回存储器的最新数据在结点内的多个处理器中的提前共享,解决拥有者不确定问题,使基于SMP的CC-NUMA系统在监听-目录两层协议方式下正常的运行。
WSRM请求的数据结构包括CMD项、W项和T项。CMD项用来标志WSRM请求,W项和T项是对WSRM请求的响应类型和是否与外部请求产生冲突的标志。如果W=1,代表收到一个忙应答WSRMBAK;否则,表示收到正常的应答WSRMEAK。如果T=1,代表收到来自外部的Intervention请求;T=0代表没有收到外部的冲突。
NC的硬件逻辑分为三大部分:第一部分实现由CPU流向NC的通信,为逻辑输出部分,包括WSRM请求产生逻辑、输出命令(命令包括请求和响应两种类型)处理逻辑和输出报文FIFO;第二部分实现由NC流向CPU的通信,为逻辑输入部分,包括输入报文FIFO和输入命令处理逻辑;第三部分是未决请求缓冲区。这三部分实现CPU与NC之间的通信,过程是:
WSRM请求产生逻辑在NC监听到总线上出现脏命中且请求的类型是READ_SH时,接收总线上的脏副本,产生相应的WSRM请求并送入输出命令处理逻辑。
输出命令处理逻辑不仅接收WSRM请求产生逻辑生成的WSRM请求,而且接收由CPU直接流出的其他命令,并统一进行处理。如果是响应类型的命令,则直接将该响应类型的命令形成内部报文送入输出报文FIFO模块。如果流出的是请求类型的命令,且该请求和未决请求缓冲区中的任何一项请求不冲突,则将该请求类型的命令形成内部报文送入输出报文FIFO等待发送,同时将该该请求命令中的请求存入未决请求缓冲区,置等待完成标志;如果该请求命令中的请求和未决请求缓冲区中的某个等待完成的请求冲突,则将该请求类型的请求放入未决请求缓冲区并置挂起标志,等待冲突解除后再次处理。
输出报文FIFO存放流出NC的报文,并等待流到网络上去。
输入命令处理逻辑首先将输入报文FIFO送来的报文转换成命令格式,再与未决请求缓冲区进行地址匹配,决定如何处理。如果是响应类型的命令,在未决请求缓冲区中找出和该响应匹配的请求项,将其从未决请求缓冲区删除,同时在未决请求缓冲区内检查是否存在被该响应对应的请求挂起的其它请求,如果有,就将这些被挂起的请求解挂,来自结点内的请求送入输出命令处理逻辑,来自外部结点的请求送入输入命令处理逻辑。如果是请求类型的命令,则判断是否与未决请求缓冲区中的任何一项冲突:如果有冲突,就将该请求命令中的请求送入未决请求缓冲区并挂起,直到冲突处理完再流入输入命令处理逻辑进行处理;否则直接将该请求命令中的请求通过总线送入处理器进行处理。
输入报文FIFO存放从网络上流入NC等待处理的报文。
未决请求缓冲区记录所有结点内还没有完成的和流入该结点的存在冲突的外部请求,提供输出命令处理逻辑和输入命令处理逻辑的访问接口,返回命令地址的匹配标识信息。未决请求缓冲区中每一项的数据结构包括:有效位Valid,目的地址Address,请求类型CMD,挂起标志位Hold,响应类型W,冲突标志位T。置位Valid项说明该未决请求缓冲区中的请求有效;否则无效。Address项表明该未决请求缓冲区中的请求需要的数据块在存储器中的地址。CMD项用于说明未决请求缓冲区中的请求的类型,包括READ_SH、READ_OWN、UPGRADE、WB、WSRM请求。Hold项置位说明该未决请求缓冲区中的请求被挂起;Hold项清0表明请求已解挂,可以处理该未决请求缓冲区中的请求。T项表示该未决请求缓冲区中的请求是否有冲突请求命中该请求,需要进行冲突处理。如果输出命令处理逻辑进行访问,则未决请求缓冲区查找所有等待完成的请求,如果没有地址相同的,则返回没有冲突的标识(T=0),通知输出命令处理逻辑可以流出命令,如果有地址相同的,则返回有冲突的标识(T=1),通知输出命令处理逻辑挂起命令;如果输入命令处理逻辑进行访问,则未决请求缓冲区对所有等待完成的命令进行地址比较,找到地址匹配的命令,提供信息返回给输入命令处理逻辑,同时对被挂起的命令进行地址比较,找到地址匹配且被挂起的命令项,根据命令的来源返回给对应的输入或输出命令处理逻辑。
WSRM请求由Home结点所在的NC进行相应的处理。具体过程是:WSRM请求由请求结点L的NC发出,Home结点H的NC收到WSRM请求后,如果目录块的状态为Dir_Private状态,则数据写入存储器,目录状态转换为Dir_Shared状态;如果请求结点L的NC收到WSRMEAK响应(即HOME处于Dir_Private时的应答),则该请求结点L的NC直接释放未决请求缓冲区;如果请求结点L的NC收到WSRMBAK(目录处于Dir_Busy时的应答),则该请求结点L的NC释放未决请求缓冲区时,需判断该未决请求缓冲区项的T是否为1(即冲突的Intervention请求是否收到),如果T=0,则请求结点L的NC不能释放该WSRM请求的资源,因为请求结点L的NC需要等待处理冲突的Intervention请求,并返回应答给其他请求者。在T=1时,表示冲突处理已经完成,请求结点L的NC在收到WSRM请求对应的应答WSRMBAK后释放WSRM请求占用的数据缓冲区。这种对结点内脏数据共享的处理方法实现了未写回存储器的最新数据在结点内的多个处理器中的提前共享,能充分利用结点内的资源,实现起来简单且方便。
采用WSRM请求的处理方法,能使CPU将最新的数据副本流出并写回存储器,但在完成对HOME结点存储器的修改之前,该NC仍然是该Cache块的拥有者,必须处理WSRM请求未完成时,其他结点流出访问对应Cache块的请求带来的冲突,具体的处理方法是:
(1)CPU请求和WSRM请求的冲突处理
在NC产生WSRM请求时,拥有数据的CPU的Cache状态处于Shared状态。如果拥有数据的CPU需要进行修改,则会流出冲突的UPGRADE请求;如果其他的CPU需要数据,则会流出冲突READ_SH和READ_OWN请求。采取的CPU请求和WSRM请求冲突处理的原则是:暂停所有冲突的UPGRADE、READ_SH或者READ_OWN的流出,等待WSRM请求完成之后,恢复冲突的UPGRADE、READ_SH或者READ_OWN请求的流出。
(2)Intervention请求与WSRM请求的冲突处理
按照目录协议,流出WSRM请求的结点在WSRM未到达HOME结点之前,该结点仍是该Cache块的拥有者,有可能收到HOME结点转发的Intervention请求,NC需要对冲突进行处理。
如果NC收到Intervention请求,发现和WSRM请求冲突,则NC处理冲突的Intervention请求,同时置WSRM请求的T=1,等待WSRM请求的应答WSRMBAK收到后,撤销WSRM请求。
a)如果冲突的Intervention请求是IREAD_SH(Intervention of REAS_SH),则NC不需处理(不失效CPU的Cache数据);
b)如果冲突的Intervention请求是IREAD_OWN(Intervention ofREAS_OWN),则NC将IREAD_OWN转为INVAL,必须失效NC所在结点内所有的共享副本;
在NC处理WSRM请求与Intervention请求冲突时,如果NC需要失效Cache中的数据(收到IREAD_OWN),则NC在向CPU发送失效请求的同时,也必须对未决请求缓冲区进行检查,如果发现有因为和WSRM请求冲突而暂停流出的UPGRADE请求,则该UPGRADE请求会被失效并由CPU负责重发。
(3)INVAL请求与WSRM请求冲突的处理
另外,WSRM请求也可能收到冲突的INVAL(Invalid)请求,发生的原因是先前的WSRMEAK响应耽误在途中,其他的结点流出了READ_OWN等请求,此时Home结点的目录状态为Dir_Shared,要对其进行失效,HOME流出的INVAL请求先于WSRMEAK到达NC,导致冲突发生。如果计算机系统采用维序路由的方式,则可以避免这种情况。
如果NC发现有冲突的INVAL请求,则将CPU的副本进行失效,返回IVACK,不等待WSRMEAK回来,让INVAL请求完成,即不判断WSRM请求是否和INVAL冲突。
采用本发明可以达到以下技术效果:
(1)解决了采用监听-目录两层协议方式的基于SMP的CC-NUMA系统对脏状态的数据共享后带来的拥有者不确定问题;
(2)实现了最新数据在结点内的提前使用;
(3)减少了结点内对脏副本数据使用的通信延迟;
(4)实现了结点内监听协议和结点间目录协议的有机融合;
附图说明:
图1是采用单层目录协议的SGI的Origin 2000体系结构示意图;
图2是监听-目录两层协议方式的基于SMP的CC-NUMA体系结构示意图;
图3是监听到脏副本情况下对同一结点内READ_OWN请求的处理流程图;
图4是监听到脏副本情况下对同一结点内READ_SH请求的处理流程图;
图5是本发明的WSRM请求的报文格式图;
图6是系统的未决请求缓冲区的数据结构图;
图7是本发明的NC的逻辑结构图;
图8是本发明的WSRM请求的处理流程图;
图9是本发明的WSRM和Intervention请求的冲突处理流程图;
具体实施方式:
图1是采用单层目录协议的SGI的Origin 2000体系结构示意图。SGI的Origin2000系统有多个处理结点组成。这些处理结点由基于交换的互连网络连接在一起,构成整个CC-NUMA系统。每个处理结点包括一个MIPSR10000处理器和一个结点控制器HUB,每个处理器都有一级和二级Cache,HUB包括存储器复位接口、互连网络接口和I/O接口。HUB硬件实现Cache一致性协议,实现分布共享存储器访问,它可以看见结点内的处理器请求在所有二级Cache不命中,不管它们是被本地还是远程满足;它从网络接收事务;也能从本地处理器Cache取得数据。
图2是监听-目录两层协议方式的基于SMP的CC-NUMA体系结构示意图。该系统由互连网络连接所有结点组成。结点内是采用监听协议的SMP系统,结点间是采用目录协议的CC-NUMA系统。每个处理结点包括多个处理器,每个处理器都配有Cache,结点还包括存储器(主存的一部分)和NC(NodeController)。NC作为结点控制器,不仅要监听总线,完成对请求/响应的处理,还要实现网络接口的功能。NC可以从网络接收事务,也能从本地处理器Cache取得数据,同时负责结点间的一致性协议的维护。
图3是在监听协议层次监听到脏副本情况下对同一结点内READ_OWN请求的处理流程图。其处理过程为:由O处理器(脏结点内的一处理器)发送数据给R处理器(请求方结点内的一处理器),且O处理器中的Cache中的状态由脏变为无效,R处理器中Cache中的状态由无效变为脏,目录块的状态仍为专有。
图4是在监听协议层次监听到脏副本情况下对同一结点内READ_SH请求的处理流程图。其处理方式和单层目录协议的相同;如果该处理器在结点内监听到O处理器中有脏副本,就由O处理器将数据发送给请求方处理器R,提供数据的O处理器Cache中的状态由脏变为无效,R处理器Cache中的状态由无效变为共享。
图5是本发明的WSRM请求的报文格式图。WSRM请求的报文包括:标志WSRM请求的CMD项和需要的标志位W和T。如果W=1,代表收到一个忙应答WSRMBAK;否则,表示返回的是正常的应答WSRMEAK。如果T=1,代表收到来自外部的Intervention请求,外部冲突请求处理完成;T=0代表没有收到外部的冲突。
图6是系统的未决请求缓冲区的数据结构图。未决请求缓冲区中每一项的数据结构包括:有效位Valid,目的地址Address,请求类型CMD,挂起标志位Hold,响应类型W,冲突标志位T。置位Valid项说明该未决请求缓冲区中的请求有效;否则无效。Address项表明该未决请求缓冲区中的请求需要的数据块在存储器中的地址。CMD项用于说明未决请求缓冲区中的请求的类型,包括READ_SH、READ_OWN、UPGRADE、WB、WSRM请求。Hold项置位说明该未决请求缓冲区中的请求被挂起;Hold项清0表明请求已解挂,可以处理该未决请求缓冲区中的请求。T项表示该未决请求缓冲区中的请求是否有冲突请求命中该请求,需要进行冲突处理。
图7是本发明的NC的逻辑结构图。NC的逻辑结构包括:WSRM请求产生逻辑、输出命令处理逻辑、输入命令处理逻辑、未决请求缓冲区(Pending RequestBuffer)、输出报文FIFO(First-In First-Out)、输入报文FIFO。
NC接收来自CPU的命令和来自网络的报文并分别进行处理。图的左半边是对CPU命令的处理部件。对CPU流出命令,NC判断是否需要产生WSRM请求:如需要,则进入WSRM请求产生逻辑生成对应的WSRM请求,并将该请求送入输出命令处理逻辑进行处理;否则,直接进入输出命令处理逻辑进行处理。输出命令处理逻辑判断命令类型并进行相应的处理。如果是响应类型的命令,则直接将该响应类型的命令形成内部报文送入输出报文FIFO模块。如果流出的是请求类型的命令,且该请求和未决请求缓冲区中的任何一项请求不冲突,则将该请求类型的命令形成内部报文送入输出报文FIFO模块等待发送,同时将该该请求命令的请求存入未决请求缓冲区,置Valid=1,标明该请求有效,目前处于等待完成阶段;如果该请求命令的请求和未决请求缓冲区中的某个等待完成的请求冲突,则将该请求类型的命令放入未决请求缓冲区并置挂起标志,置Hold项为1,等待冲突解除后再次处理。输出报文FIFO存放流出NC的报文,并等待流到网络上去。
图的右半边是对网络的报文的处理部件。输入报文FIFO存放从网络上流入NC的报文。输入命令处理逻辑将输入报文FIFO送来的报文转换成命令格式,再与未决请求缓冲区进行地址匹配,决定如何处理。如果是响应类型的命令,在未决请求缓冲区中找出和该响应匹配的请求项,将其从未决请求缓冲区删除,同时在未决请求缓冲区内检查是否存在被该响应对应的请求挂起的其它请求,如果有,就将这些被挂起的请求解挂,并将其送入输入或是输出命令处理逻辑进行处理。如果是请求类型的命令,则判断是否与未决请求缓冲区中的任何一项冲突:如果有冲突,就将该请求送入未决请求缓冲区并挂起,直到冲突处理完再流入输入命令处理逻辑进行处理;否则直接将该请求通过总线送入处理器进行处理。
图8是在目录协议层次本发明的WSRM请求的处理流程图。WSRM请求处理涉及的结点包括请求结点L和Home结点H。WSRM请求首先由请求结点L的NC发出,Home结点H的NC收到WSRM请求后,如果目录块的状态为Dir_Private状态,则数据写入存储器,目录状态转换为Dir_Shared状态。如果请求结点L的NC收到WSRMEAK响应,则该请求结点L的NC直接释放未决请求缓冲区;如果请求结点L的NC收到WSRMBAK(收到目录的忙应答),则该请求结点L的NC释放未决请求缓冲区时,需判断该未决请求缓冲区项的T是否为1(即冲突的Intervention请求是否收到),如果T=0,则请求结点L的NC不能释放该WSRM请求的资源,因为请求结点L的NC需要等待处理冲突的Intervention请求,并返回应答给其他请求者。在T=1时,表示请求结点L的NC已经收到冲突的Intervention请求,并且冲突处理已经完成,请求结点L的NC在收到WSRM请求对应的应答WSRMBAK后释放WSRM请求占用的数据缓冲区。
图9本发明的WSRM和Intervention请求的冲突处理流程图。这种情况的处理可以利用目录状态的含义,由Home结点的NC转发WSRM请求携带的有效数据,有效完成数据的传递和目录状态转换的过程。在一个结点流出WSRM请求并等待完成期间,另一个请求结点L也发出了对该数据块的访问请求(READ_SH或者READ_OWN),并且先于WSRM请求到达Home结点,则该访问请求将由Home结点的NC接收并转发给产生WSRM请求的结点R。结点R的NC会在收到WSRM请求对应的响应之前收到冲突的Intervention请求,需要立即处理该冲突情况。如果结点R的NC发现有冲突的Intervention请求,则根据Intervention请求的类型进行处理,如果是IREAD_OWN,则将CPU的副本进行失效;如果是IREAD_SH,则不进行失效操作。两种冲突情况都要标记未决请求缓冲区内等待完成的WSRM请求的状态位T=1(Intervention请求命中),让Intervention请求完成,最后请求结点R的NC会收到WSRMBAK应答,WSRM请求完成。对于请求结点L,将收到Home结点NC处理WSRM请求时转发WSRM请求携带数据的响应报文。
Claims (2)
1.一种目录协议对多处理器结点内脏数据共享的支持方法,采用监听-目录两层协议方式,其特征在于在结点控制器NC的硬件逻辑中设计WSRM请求产生逻辑,由WSRM请求产生逻辑监听总线,当监听到总线上出现脏命中且请求的类型为READ SH时,NC接收总线上的脏副本,产生一个可以对目录块进行操作的WSRM请求,由Home结点所在的NC对WSRM请求进行相应的处理,将最新副本写回存储器,实现未写回存储器的最新数据在结点内的多个处理器中的提前共享,解决拥有者不确定问题,使基于SMP的CC-NUMA系统在监听-目录两层协议方式下正常的运行,具体方法是:
1.1设计WSRM请求的数据结构,方法是:WSRM请求的数据结构包括CMD项、W项和T项:CMD项用来标志WSRM请求,W项和T项是对WSRM请求的响应类型和是否与外部请求产生冲突的标志,如果W=1,代表收到一个忙应答WSRMBAK;否则,返回正常的应答WSRMEAK;如果T=1,代表收到来自外部的Intervention请求;T=0代表没有收到外部的冲突;
1.2在结点控制器NC的硬件逻辑中设计WSRM请求产生逻辑,方法是:将NC的硬件逻辑分为三大部分:第一部分实现由CPU流向NC的通信,为逻辑输出部分,包括WSRM请求产生逻辑、输出命令处理逻辑和输出报文FIFO;第二部分实现由NC流向CPU的通信,为逻辑输入部分,包括输入报文FIFO和输入命令处理逻辑;第三部分是未决请求缓冲区;这三部分实现CPU与NC之间的通信,过程是:
1.2.1WSRM请求产生逻辑在NC监听到总线上出现脏命中且请求的类型是READ SH时,接收总线上的脏副本,产生相应的WSRM请求并送入输出命令处理逻辑;
1.2.2输出命令处理逻辑不仅接收WSRM请求产生逻辑生成的WSRM请求,而且接收由CPU直接流出的其他命令,并统一进行处理,如果是响应类型的命令,则直接将该响应类型的命令形成内部报文送入输出报文FIFO模块;如果流出的是请求类型的命令,且该请求和未决请求缓冲区中的任何一项请求不冲突,则将该请求类型的命令形成内部报文送入输出报文FIFO等待发送,同时将该请求命令中的请求存入未决请求缓冲区,置等待完成标志;如果请求命令中的请求和未决请求缓冲区中的某个等待完成的请求冲突,则将该请求类型的命令放入未决请求缓冲区并置挂起标志,等待冲突解除后再次处理;
1.2.3输出报文FIFO存放流出NC的报文,并等待流到网络上去;
1.2.4输入命令处理逻辑首先将输入报文FIFO送来的报文转换成命令格式,再与未决请求缓冲区进行地址匹配,决定如何处理:如果是响应类型的命令,在未决请求缓冲区中找出和该响应匹配的请求项,将其从未决请求缓冲区删除,同时在未决请求缓冲区内检查是否存在被该响应对应的请求挂起的其它请求,如果有,就将这些被挂起的请求解挂,结点内请求送入输入命令处理逻辑,外部结点的请求送入输出命令处理逻辑;如果是请求类型的命令,则判断是否与未决请求缓冲区中的任何一项冲突:如果有冲突,就将该请求命令中的请求送入未决请求缓冲区并挂起,直到冲突处理完再流入输入命令处理逻辑进行处理;否则直接将该请求命令中的请求通过总线送入处理器进行处理;
1.2.5输入报文FIFO存放从网络上流入NC等待处理的报文;
1.2.6未决请求缓冲区记录所有结点内还没有完成的和流入该结点的存在冲突的外部请求,提供输出命令处理逻辑和输入命令处理逻辑的访问接口,返回命令地址的匹配标识信息,未决请求缓冲区中每一项的数据结构包括:有效位Valid,目的地址Address,请求类型CMD,挂起标志位Hold,响应类型W,冲突标志位T,置位Valid项说明该未决请求缓冲区中的请求有效;否则无效;Address项表明该未决请求缓冲区中的请求需要的数据块在存储器中的地址;CMD项用于说明未决请求缓冲区中的请求的类型,包括READ_SH、READ_OWN、UPGRADE、WB、WSRM请求;Hold项置位说明该未决请求缓冲区中的请求被挂起;Hold项清0表明请求已解挂,可以处理该未决请求缓冲区中的请求;T项表示该未决请求缓冲区中的请求是否有冲突请求命中该请求,需要进行冲突处理;如果输出命令处理逻辑进行访问,则未决请求缓冲区查找所有等待完成的请求,如果没有地址相同的,则返回没有冲突的标识即T=0,通知输出命令处理逻辑可以流出命令,如果有地址相同的,则返回有冲突的标识即T=1,通知输出命令处理逻辑挂起命令;如果输入命令处理逻辑进行访问,则未决请求缓冲区对所有等待完成的命令进行地址比较,找到地址匹配的命令,提供信息返回给输入命令处理逻辑,同时对被挂起的命令进行地址比较,找到地址匹配且被挂起的命令项,根据命令的来源返回给对应的输入或输出命令处理逻辑;
1.3由Home结点所在的NC对WSRM请求进行处理,具体过程是:WSRM请求由请求结点L的NC发出,Home结点H的NC收到WSRM请求后,如果目录块的状态为Dir_Private状态,则数据写入存储器,目录状态转换为Dir_Shared状态;如果请求结点L的NC收到WSRMEAK响应即HOME处于Dir_Private时的应答,则该请求结点L的NC直接释放未决请求缓冲区;如果请求结点L的NC收到WSRMBAK即目录处于Dir_Busy时的应答,则该请求结点L的NC释放未决请求缓冲区时,需判断该未决请求缓冲区项的T是否为1,如果T=0,则请求结点L的NC不释放该WSRM请求的资源,请求结点L的NC处理冲突的Intervention请求,并返回应答给其他请求者;在T=1时,表示冲突处理已经完成,请求结点L的NC在收到WSRM请求对应的应答WSRMBAK后释放WSRM请求占用的数据缓冲区。
2如权利要求1所述的目录协议对多处理器结点内脏数据共享的支持方法,其特征在于采用WSRM请求的处理方法,能使CPU将最新的数据副本流出并写回存储器,但在完成对HOME结点存储器的修改之前,该NC仍然是该Cache块的拥有者,必须处理WSRM请求未完成时,其他结点流出对应Cache块的请求带来的冲突,具体的处理方法是:
2.1CPU请求和WSRM请求的冲突处理方法是:在NC产生WSRM请求时,拥有数据的CPU的Cache状态处于Shared状态,如果拥有数据的CPU需要进行修改,则会流出冲突的UPGRADE请求;如果其他的CPU需要数据,则会流出冲突READ_SH和READ_OWN请求,采取的CPU请求和WSRM请求冲突处理的原则是:暂停所有冲突的UPGRADE、READ_SH或者READ_OWN的流出,等待WSRM请求完成之后,恢复冲突的UPGRADE、READ_SH或者READ_OWN请求的流出;
2.2Intervention请求与WSRM请求的冲突处理:如果NC收到Intervention请求,发现和WSRM请求冲突,则NC处理冲突的Intervention请求,同时置WSRM请求的T=1,等待WSRM请求的应答WSRMBAK收到后,撤销WSRM请求,
a)如果冲突的Intervention请求是IREAD_SH,则NC不处理;
b)如果冲突的Intervention请求是IREAD_OWN,则NC将IREAD_OWN转为INVAL,必须失效NC所在结点内所有的共享副本;
在NC处理WSRM请求与Intervention请求冲突时,如果NC需要失效Cache中的数据即收到IREAD_OWN时,则NC在向CPU发送失效请求的同时,也必须对未决请求缓冲区进行检查,如果发现有因为和WSRM请求冲突而暂停流出的UPGRADE请求,则该UPGRADE请求会被失效并由CPU负责重发;
2.3INVAL请求与WSRM请求冲突的处理:如果NC发现有冲突的INVAL请求,则将CPU的副本进行失效,返回IVACK,不等待WBEAK回来,让INVAL请求完成,即不判断WSRM请求是否和INVAL冲突。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2005100313952A CN1328670C (zh) | 2005-03-30 | 2005-03-30 | 目录协议对多处理器结点内脏数据共享的支持方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB2005100313952A CN1328670C (zh) | 2005-03-30 | 2005-03-30 | 目录协议对多处理器结点内脏数据共享的支持方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1664795A CN1664795A (zh) | 2005-09-07 |
CN1328670C true CN1328670C (zh) | 2007-07-25 |
Family
ID=35035897
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNB2005100313952A Expired - Fee Related CN1328670C (zh) | 2005-03-30 | 2005-03-30 | 目录协议对多处理器结点内脏数据共享的支持方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN1328670C (zh) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101470669B (zh) * | 2007-12-28 | 2011-02-16 | 无锡江南计算技术研究所 | 多缓存数据一致性的处理方法及主存处理机 |
CN102708190B (zh) * | 2012-05-15 | 2016-09-28 | 浪潮电子信息产业股份有限公司 | 一种CC-NUMA系统中结点控制芯片目录Cache的方法 |
CN105912477B (zh) * | 2016-04-05 | 2019-01-01 | 浪潮电子信息产业股份有限公司 | 一种目录读取的方法、装置及系统 |
CN116959289B (zh) * | 2023-09-21 | 2024-03-22 | 山东通维信息工程有限公司 | 一种基于车路协同技术的智慧停车系统及方法 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5097409A (en) * | 1988-06-30 | 1992-03-17 | Wang Laboratories, Inc. | Multi-processor system with cache memories |
CN1176433A (zh) * | 1996-09-09 | 1998-03-18 | 株式会社东芝 | 高速缓存清理装置以及具备该装置的计算机系统 |
CN1252142A (zh) * | 1997-04-14 | 2000-05-03 | 国际商业机器公司 | 多处理器计算机系统中的读取操作 |
-
2005
- 2005-03-30 CN CNB2005100313952A patent/CN1328670C/zh not_active Expired - Fee Related
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5097409A (en) * | 1988-06-30 | 1992-03-17 | Wang Laboratories, Inc. | Multi-processor system with cache memories |
CN1176433A (zh) * | 1996-09-09 | 1998-03-18 | 株式会社东芝 | 高速缓存清理装置以及具备该装置的计算机系统 |
CN1252142A (zh) * | 1997-04-14 | 2000-05-03 | 国际商业机器公司 | 多处理器计算机系统中的读取操作 |
Non-Patent Citations (1)
Title |
---|
虚拟存储技术研究 郭御风,李琼,刘光明,刘衡竹,计算机应用研究,第2卷 2004 * |
Also Published As
Publication number | Publication date |
---|---|
CN1664795A (zh) | 2005-09-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20010013089A1 (en) | Cache coherence unit for interconnecting multiprocessor nodes having pipelined snoopy protocol | |
JP3661761B2 (ja) | 共用介入サポートを有する不均等メモリ・アクセス(numa)データ処理システム | |
US6615319B2 (en) | Distributed mechanism for resolving cache coherence conflicts in a multi-node computer architecture | |
US7814279B2 (en) | Low-cost cache coherency for accelerators | |
CN101958834B (zh) | 支持高速缓存一致的片上网络系统及数据请求方法 | |
JP5575870B2 (ja) | 部分読出と非スヌープアクセスとの間のメモリ順序付け要件の充足 | |
KR100404608B1 (ko) | 대칭형 멀티프로세서용 버스식 캐시-코히런스 프로토콜을지원하기 위해 분산 시스템 구조를 이용하는 방법 및 장치 | |
US8015366B2 (en) | Accessing memory and processor caches of nodes in multi-node configurations | |
JP2004005657A (ja) | 情報処理方法および装置 | |
US7543115B1 (en) | Two-hop source snoop based cache coherence protocol | |
JPH04271452A (ja) | マルチプロセッサシステム | |
US6950913B2 (en) | Methods and apparatus for multiple cluster locking | |
JP2000112910A (ja) | 非一様メモリ・アクセス・コンピュ―タ・システム及びその操作方法 | |
JPH10187633A (ja) | 外部装置とメモリ・ブロックを共用できるようにする方法および装置 | |
JP2005539282A (ja) | 単一のコヒーレントなシステム内の分散コンピュータ・ノードにキャッシュ・コヒーレンスを提供するのにグローバル・スヌープを使用する方法および装置 | |
US8195890B1 (en) | Method for maintaining cache coherence using a distributed directory with event driven updates | |
CN1328670C (zh) | 目录协议对多处理器结点内脏数据共享的支持方法 | |
US7249224B2 (en) | Methods and apparatus for providing early responses from a remote data cache | |
US20050262250A1 (en) | Messaging protocol | |
JPH07152647A (ja) | 共有メモリマルチプロセッサ | |
CN106201939A (zh) | 面向gpdsp架构的多核目录一致性装置 | |
JPH10187534A (ja) | コヒーレントメモリシステムにおいて強い順序づけを維持する方法およびシステム | |
US7162589B2 (en) | Methods and apparatus for canceling a memory data fetch | |
JP2021522610A (ja) | データ処理ネットワーク内の転送プロトコル | |
JP4689783B2 (ja) | 分散共有メモリ型並列計算機 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20070725 Termination date: 20150330 |
|
EXPY | Termination of patent right or utility model |