CN115933860A

CN115933860A - 一种处理器系统、处理请求的方法及计算设备

Info

Publication number: CN115933860A
Application number: CN202310137913.7A
Authority: CN
Inventors: 王玉姣; 高军; 赵天磊; 丁哲
Original assignee: Phytium Technology Co Ltd
Current assignee: Phytium Technology Co Ltd
Priority date: 2023-02-20
Filing date: 2023-02-20
Publication date: 2023-04-07
Anticipated expiration: 2043-02-20
Also published as: CN115933860B

Abstract

本申请提供了一种处理器系统、处理请求的方法及计算设备，该处理器系统包括：第一模块；第二模块，通过支持重试机制的总线协议与所述第一模块通信连接；其中，所述第一模块用于执行以下操作：向所述第二模块发送一个或多个请求；基于所述第二模块针对所述一个或多个请求反馈的重试响应，确定针对所述第二模块的请求发送策略。本申请实施例通过基于请求接收模块针对一个或多个请求反馈的重试响应，调整请求发送模块的请求发送策略，避免了在请求接收模块拥塞时，多次发送请求带来的功耗问题，有助于优化系统功耗。

Description

一种处理器系统、处理请求的方法及计算设备

技术领域

本申请涉及计算机技术领域，更为具体的，涉及一种处理器系统、处理请求的方法及计算设备。

背景技术

随着片上系统（system on chip，SOC）复杂度的剧烈提升，降低系统功耗也变得越来越重要。SOC系统可以使用支持重试（retry）机制总线协议进行通信，当系统中各个模块之间进行大规模的事务传输时，可能会导致大量的请求被retry，严重影响系统的功耗。

发明内容

本申请提供一种处理器系统、处理请求的方法及计算设备。下面对本申请实施例涉及的各个方面进行介绍。

第一方面，提供一种处理器系统，所述处理器系统包括：第一模块；第二模块，通过支持重试机制的总线协议与所述第一模块通信连接；其中，所述第一模块用于执行以下操作：向所述第二模块发送一个或多个请求；基于所述第二模块针对所述一个或多个请求反馈的重试响应，确定针对所述第二模块的请求发送策略。

作为一种可能的实现方式，所述请求发送策略用于降低向所述第二模块发送请求的频率。

作为一种可能的实现方式，所述请求发送策略包括以下中的一种或多种：暂停向所述第二模块发送请求；以及暂停处理器核的数据预取操作。

作为一种可能的实现方式，所述第一模块基于第一时钟频率工作，所述第二模块基于第二时钟频率工作，且所述第一时钟频率高于所述第二时钟频率。

作为一种可能的实现方式，所述第一模块基于以下中的一种或多种确定所述请求发送策略：所述第二模块反馈的重试响应的数量；以及所述第二模块反馈的重试响应对应的请求的类型。

作为一种可能的实现方式，所述处理器系统还包括：计数器，用于统计所述第二模块反馈的重试响应的数量。

作为一种可能的实现方式，所述计数器设置在所述第一模块上。

作为一种可能的实现方式，所述第一模块还用于：调整所述第一模块的流水线的调度策略。

作为一种可能的实现方式，所述调度策略包括：延后处理所述重试响应对应的请求所关联的指令。

作为一种可能的实现方式，所述总线协议为一致性集线器接口协议。

第二方面，提供一种处理请求的方法，所述处理请求的方法应用于处理器系统，所述处理器系统包括第一模块和第二模块，所述第二模块通过支持重试机制的总线协议与所述第一模块通信连接，所述方法包括：所述第一模块向所述第二模块发送一个或多个请求；基于所述第二模块针对所述一个或多个请求反馈的重试响应，所述第一模块确定针对所述第二模块的请求发送策略。

作为一种可能的实现方式，所述处理器系统还包括计数器，所述计数器用于统计所述第二模块反馈的重试响应的数量。

作为一种可能的实现方式，所述第一模块还用于调整所述第一模块的流水线的调度策略。

第三方面，提供了一种计算设备，该计算设备包括如第一方面任意一种实现方式的处理器系统。

本申请实施例通过基于请求接收模块针对一个或多个请求反馈的重试响应，调整请求发送模块的请求发送策略，避免了在请求接收模块拥塞时，多次发送请求带来的功耗问题，有助于优化系统功耗。

附图说明

图1为本申请实施例提供的一种处理器系统的结构示意图。

图2为本申请实施例提供的另一种处理器系统的结构示意图。

图3为本申请实施例提供的重试计数器的结构示意图。

图4为本申请实施例提供的一种计算设备的结构示意图。

图5为本申请实施例提供的一种处理请求的方法的流程示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。

随着现代集成电路技术的不断发展，高性能处理器系统也因支持大规模复杂计算而变得集成度更高、模块互联更加复杂。与此同时，随着片上系统复杂度的剧烈提升，如何降低系统功耗也变得越来越重要。

功耗的增加可能会带来处理器系统芯片温度的上升，高温可能会降低芯片的可靠性与寿命，使得处理器芯片在高负荷下的稳定性严重降低。高功耗可能同步带来用电成本、散热成本以及环境噪音等问题。

目前处理器系统在功耗控制上已经有了一套成熟的方案，通常通过动态功耗管理与静态功耗管理来完成系统功耗管理。动态功耗是指在开关逻辑状态转换过程中所消耗的功率，静态功耗（泄漏功率）是指在晶体管不进行开关动作时消耗的功率。但是，对于复杂的SOC系统，功耗控制的关键点在于单个模块的功耗管理，如处理器核、访存模块、互联总线、设备等功耗管理。

在实际使用中，SOC系统中的各个模块之间会进行大规模的事务传输，在一些情况下，访问请求的处理会存在拥塞。如果SOC的互联总线中应用的接口协议，如CHI，支持重试机制，在上述请求拥塞的情况下，可能会导致大量的请求被retry，严重影响系统的功耗。

以CHI协议为例，对请求拥塞导致大量请求被retry的情况进行介绍。目前通用的SOC系统中，CHI协议常作为一种通用接口协议，普遍应用于总线互联模块中，如，通过CHI协议，处理器核与互联总线之间会进行大规模的事务传输。

CHI协议两侧的模块通常工作在不同的时钟域，低速下游模块（互联总线）对访问请求处理会存在拥塞的情况，可能会导致处理器核的大量请求被Retry，从而影响系统功耗。

为了解决上述问题，本申请实施例提供了一种处理器系统，通过基于请求接收模块针对一个或多个请求反馈的重试响应，调整请求发送模块的请求发送策略，避免了在请求接收模块拥塞时，多次发送请求带来的功耗问题，有助于优化系统功耗。

图1为本申请实施例提供的一种处理器系统的结构示意图。处理器系统100例如可以为前文提到的片上系统。

参见图1，本申请实施例提供的系统100可以包括第一模块110和第二模块120。下面结合图1对系统100的各个组成部分的功能和实现方式进行详细描述。

处理器系统中可以包括处理器核、互联总线、访存模块、外设等模块。处理器系统中的各个模块可以采用多种总线协议中的一种或多种进行数据交互，如CHI总线协议。

第一模块110可以为处理器核、互联总线、访存模块、外设等。第二模块120可以为通过支持重试机制的总线协议与第一模块110通信的模块，例如，第二模块120可以为处理器核、互联总线、访存模块、外设等。作为一个示例，如果第一模块110为处理器核，第二模块120可以为与第一模块110通过支持重试机制的总线协议进行通信的互联总线模块；如果第一模块110为互联总线模块，第二模块120可以为与第一模块110通过支持重试机制的总线协议进行通信的访存模块。

重试机制是指当请求处理模块不能接收或处理请求发送模块的请求时，会给请求发送模块发送针对不能接受的请求的重试响应。例如，在该SOC系统中，第一模块110为处理器核，第二模块120为总线互联模块，第一模块110与第二模块120通过支持重试机制的CHI协议进行通信。通常处理器核会工作在较高的时钟频率，当处理器核发出请求事务时，受限于下游工作的较低时钟频率，互联模块会将未处理请求暂存于内部缓冲区中。若短时间请求过多导致缓冲区存满，而不能接收请求，此时互联会对请求返回重试响应（RetryAck）。

在一些实施例中，第一模块110可以向所述第二模块120发送一个或多个请求。在实际使用中可以将发出请求的模块（即第一模块110）称为请求模块、请求端或主模块（master，也可以称为requester），将返回响应的模块（即第二模块120）称为响应模块、响应端或从模块（slaver，也称为completer或endpoint）。请求端和响应端通常工作在不同的时钟域，这种情况下，也可以将发出请求的模块称为高速上游模块，将响应模块称为低速下游模块。

第一模块110还可以基于第二模块120针对上述一个或多个请求反馈的重试响应，确定针对第二模块120的请求发送策略。

基于重试机制的总线协议，在第一模块110向第二模块发送请求之后，会接收到第二模块120针对该请求的响应，该响应可以包括多种类型，如重试响应。如果第二模块120当前无法处理该请求，第二模块120会针对该请求发送重试响应。如果第二模块120当前可以处理该请求，则第二模块120针对该请求不会发送重试响应，而是其他类型的响应。

如前文所述，当第一模块110为处理器核，第二模块120为互联总线模块时，如果第二模块120的缓存区存满无法接收新的请求时，会针对第一模块110发送的一个或多个请求向第一模块110发送重试响应；如果第二模块120的缓存区只能缓存一个或多个请求中的部分请求，则会针对第一模块110发送的一个或多个请求中无法接收处理的请求向第一模块110发送重试响应，一个或多个请求中可以缓存处理的请求向第一模块110发送其他类型的响应。

第一模块110可以基于第二模块120针对一个或多个请求反馈的重试响应，确定针对第二模块120的请求发送策略。作为一种实现方式，第一模块110可以基于第二模块120针对一个或多个请求反馈的重试响应的数量，确定针对第二模块120的请求发送策略。

如果第二模块120针对一个或多个请求反馈的重试响应的数量较多，也就是说当前第二模块120无法处理更多的请求，此时第一模块110如果继续向第二模块120发送请求，则该请求大概率是无法被处理的，反而会对系统功耗造成影响。这种情况下，针对第二模块120的请求发送策略可以用于降低向第二模块120发送请求的频率，从而优化系统功耗。

本申请实施例通过基于请求接收模块针对一个或多个请求反馈的重试响应，确定请求发送模块的请求发送策略，避免了在请求接收模块拥塞时，多次发送请求带来的功耗问题，有助于优化系统功耗。

第一模块可以基于第一时钟频率工作，第二模块可以基于第二时钟频率工作，在实际使用时，通常第一时钟频率高于第二时钟频率。而且在这种情况下，第二模块处更容易发生请求拥塞，此时采用本申请实施例提供的方法，对于处理器系统的功耗优化效果更好。

请求发送策略可以包括以下中的一种或多种：暂停向第二模块发送请求；以及暂停处理器核的数据预取操作。

作为一种实现方式，该请求发送策略可以为暂停向所述第二模块发送请求。这种方式能够避免在请求拥塞的情况下，无效的请求发送操作，从而降低系统功耗，而且实现简单。

作为另一种实现方式，第一模块可以为处理器核中的L2缓存（cache）或L3 cache，基于第二模块针对一个或多个请求反馈的重试响应，可以动态对L2cache与L3 cache的访问序列进行调整，动态关闭与开启处理器核的数据预取操作，节省下游访问的带宽。

由于数据预取操作为针对流水线需求推测的待使用数据，而预取数据有可能未命中，此时处理器核还是需要发送数据读取请求，因此暂停数据预取操作可以在不影响处理器系统功能的情况下，优化系统功耗。

在一些情况下，第二模块反馈的重试响应对应的请求可能会随着拥塞情况的好转而被处理，因此，这里提到的重试响应的数量是指当前第二模块无法处理的请求的数量，也就是说，重试响应的数量可以为第一模块接收到所有重试响应的数量减去重试响应对应的请求被处理的数量。

为了获取第二模块反馈的重试响应的数量，作为一种实现方式，处理器系统还可以包括计数器，该计数器可以用于统计第二模块反馈的重试响应的数量。如果第一模块发出的请求被拥塞，即第二模块当前无法处理该请求（如收到针对该请求的重发响应），则计数器的计数增加，如果该请求被第二模块执行，则计数器的计数减少。

如前文所述，第一模块工作的时钟频率可能高于第二模块工作的时钟频率，因此为了降低跨时钟域带来的逻辑复杂度，作为一种实现方式，可以将计数器设置在第一模块上，也就是说，计数器工作在第一模块工作的时钟域（时钟频率）。如此一来，当第一模块发出一个或多个请求时，计数器可以及时处理第一模块发送的请求。另一方面，此时第二模块工作的时钟频率低于计数器的时钟频率，对于第二模块针对一个或多个请求的反馈的重试响应的跨时钟域处理更容易一些。

在计数器实现上述功能的过程中，需要确定第二模块反馈的重发响应与第一模块发出的请求的对应关系。一般来说，一个请求（如请求事务包）中，可能包括该请求的事务ID、地址以及操作码（opcode）等信息，而一个响应中可能包括响应类型、事务ID以及操作码等信息。作为一种实现方式，可以通过重发响应中的事务ID和请求中的事务ID确定重发响应和请求的对应关系。

但是，当一个请求被执行之后，该请求对应的事务ID会被释放掉，以供其他请求使用，也就是说，事务ID具有时效性。如果仅根据事务ID识别请求和响应的对应关系，可能会存在对应关系识别不准确的情况。例如，在一些情况下，同一个请求可能包括不止一个响应事务包。以一个请求的重发响应包括两个响应事务包为例，如果根据接收到的第一个响应事务包的事务ID确定该响应与请求的对应关系，当接收到第二个响应事务包时，可能会将该响应事务包识别为其他请求的响应。因此，作为一种实现方式，可以通过重发响应中的事务ID、操作码和请求中的事务ID、操作码确定重发响应和请求的对应关系。

在实际使用中，如果第一模块重发拥塞的请求，则意味着该请求将被处理，因此可以根据拥塞请求被重发的情况确定拥塞请求被处理的情况。由于拥塞的请求重新发送时，请求中包含的地址是相同，因此，作为一种实现方式，可以根据重发请求的地址和拥塞请求的地址确定拥塞请求被处理的情况。

由于一个或多个请求对应的响应可能存在延迟，因此，作为一种实现方式，可以对上述请求及响应相关的信息进行缓存。

为了实现上述功能，处理器系统还可以包括集中控制模块，该集中控制模块可以对请求和响应进行解析，以获取请求的关键字段，如请求的事务ID、操作码、地址以及响应的关键字段如事务ID、操作码等信息。例如，集中控制模块可以包括请求解析模块，用于对请求进行解析，识别出请求的关键字段；集中控制模块也可以包括响应解析模块，用于对响应进行解析，识别出响应的关键字段。

另外，集中控制模块还可以根据解析结果确定计数器的工作状态。例如，如果第二模块当前无法处理第一模块发送的请求（如收到针对该请求的重试响应），则集中控制模块可以生成一种计数器控制信号，以控制计数器的计数增加。如果该请求被第二模块执行，则集中控制模块可以生成另一种计数器控制信号，以控制计数器的计数减少。

前文提到，第一模块可以基于第二模块反馈的重试响应的数量确定请求发送策略。作为一种实现方式，可以通过设置针对第二模块反馈的重试响应的数量的阈值，确定请求发送策略。例如，设置重试响应的拥塞上限值，当针对第二模块反馈的重试响应的数量达到拥塞上限值时，可以确定第一模块的请求发送策略，如第一模块暂停向第二模块发送请求。又如，设置重试响应的拥塞下限值，当针对第二模块反馈的重试响应的数量达到拥塞下限值时，可以确定第一模块的请求发送策略，如第一模块恢复向第二模块发送请求。

作为一种实现方式，可以根据重试响应数量对应的阈值设置计数器的计数值的阈值，以确定请求发送的策略。相应的，计数器的计数值的阈值也可以包括拥塞上限值和拥塞下限值，根据计数值与拥塞上限值、拥塞下限值的关系可以确定第一模块的请求发送策略。

在一些实施例中，集中控制模块还可以根据计数器的统计结果及对应的阈值生成控制信号，该控制信号可以用于控制第一模块执行对应的请求发送策略。例如，控制信号可以包括暂定发送请求信号以及恢复发送请求信号。

集中控制模块可以单独设置，也可以与前文所述的计数器集成在一起。如果将集中控制模块和计数器集成在一起，能够减少新增模块与第一模块以及第二模块之间的数据接口以及相关控制，使用起来更加方便。

需要说明的是，如前文所述，针对请求的响应可以包括多种类型的响应，本申请实施例可以通过重试响应的相关信息，如关键字段确定第一模块的请求发送策略。因此，在上述确定第二模块反馈的重试响应与第一模块发出的请求的对应关系之前，可以先识别第一模块接收到的响应的类型。如果接收到的响应的类型为重试响应类型，则基于该重试响应可以确定其与第一模块发出的请求的对应关系。

在一些实现方式中，第一模块还可以基于第二模块反馈的重试响应对应的请求的类型，或者基于第二模块反馈的重试响应对应的请求的类型以及第二模块反馈的重试响应的数量确定请求发送策略。

重试响应对应的请求的类型可以包括读访问和写访问等类型，当接收到某种类型的重试响应，则意味着该类型的重试响应暂时无法被处理，因此，可以基于重试响应调整第一模块的流水线调度策略，此处提到的第一模块可以为处理器核。

作为一种实现方式，如果当前某种类型的请求处于拥塞状态，则可以调整第一模块的流水线调度策略，如先执行其他类型的请求。作为另一种实现方式，如果接收到某个请求的重试响应，则可以延后处理该请求所关联的指令。与该请求所关联的指令，例如可以为与该指令的操作数存在相关性的指令。

本申请实施例通过基于重试响应调整流水线的调度策略，能够优化流水线的执行效率，提高处理器核的性能。

CHI协议支持重发机制，本申请实施例提供的处理器系统可以为支持CHI协议的处理器系统。下文以使用CHI协议进行通信的SOC系统为例，详细描述本申请的装置实施例。

图2为本申请实施例提供的另一种处理器系统的结构示意图。

参见图2，处理器系统200可以包括第一模块210、第二模块220以及重试计数器230。其中，第一模块210可以包括请求发送单元211和响应接收单元212，重试计数器230可以包括请求解码模块231和响应解码模块232。

第一模块210与第二模块220通过请求发送通道以及响应接收通道通信连接，其中，请求发送通道用于第一模块210向第二模块220发送请求，响应接收通道用于第一模块210接收第二模块220针对请求的响应。

重试计数器230与第一模块210交互的信号可以包括请求信号、响应信号以及控制信号。其中，重试计数器230可以通过请求解码单元231和响应解码单元232对请求信号和响应信号进行解析获取其对应的信息；重试计数器230可以根据请求信号和响应信号的信息生成针对第一模块的控制信号，用于控制第一模块的请求发送策略。请求解码单元231和响应解码单元232可以进行数据交互。

通过在处理器核上游的第一模块210处设置重试计数器230，对高速上游（即第一模块210，或称master模块）产生的每个请求以及低速下游（即第二模块220，或称slave模块）的重试响应进行计数。该重试计数器230可以用于统计被重试的请求类型与数目等信息，若请求被拥塞，计数器增加，若请求被执行，计数器减少。进一步地，在重试计数器230中可以设置计数值的阈值范围，实时监控请求拥塞与处理的情况，当被重试的请求数量达到设置的阈值时，会触发一个暂停/恢复控制信号给第一模块210，从而动态调整第一模块210向第二模块220发送请求的频次，来降低拥塞产生时的瞬时功耗。

图3为本申请实施例提供的重试计数器的结构示意图。重试计数器300可以包括请求解码模块310、响应解码模块320、计数器模块330、请求存储区340以及重试请求存储区350。其中，计数器模块330可以包括集中控制单元331、比较单元332、计数单元333。

为了避免跨时钟域带来的逻辑复杂度，重试计数器300可以工作在高速上游master的时钟域。

重试计数器300可以基于CHI的请求通道，对上游master模块向下游slave模块发出的CHI请求进行分析与统计，将请求关键字段，如请求类型、请求地址、请求事务ID等参数记录到一块存储空间，如请求存储区340。同时，重试计数器300可以基于CHI的响应通道，对接收到下游slave模块发来的CHI响应进行计数，与此同时，记录响应的响应类型、响应事务ID等参数。

通过分析请求通道与响应通道的ID和/或opcode对应关系可以定位被重试的请求。当接收到的响应类型为重试响应时，控制计数单元333进行加一操作，若被拥塞的请求后来被处理，控制计数单元333进行减一操作。通过对整个请求/响应通道的同步计数，重试计数器300可实时监控CHI事务的拥塞情况。

当计数单元333的计数值达到拥塞阈值上限时，重试计数器300可触发一个暂停操作发给上游master模块，使上游master模块暂停发出请求，降低功耗。当拥塞请求被陆续处理，计数单元333的计数值到达拥塞阈值下限时，可触发一个恢复操作发给上游master模块，恢复上游master模块发出请求的操作。如此一来，既可以保证不会重复retry造成功耗浪费，也可以避免协议通道空转，造成资源浪费。

为了便于理解，下文结合图3，对重试计数器300的工作过程进行介绍。

重试计数器300可以实时接收高速上游master模块产生的请求（Reqs）信号，同时通过请求解码模块310对请求进行解析，解析出识别请求的事务ID（TxnID）、地址（addr）、opcode等关键字段，并存储到请求存储区340中。在上游master模块发出请求的过程中，重试计数器300持续进行分析与记录。

与此同时，重试计数器300可以接收低速下游slave模块产生的响应（Rsps）信号，通过响应解码模块320对响应进行解析，解析出识别响应的TxnID、opcode等关键字段。在解析出响应的关键字段后，响应解码模块320会将关键字段传输给集中控制单元（ctrl）331进行运算。

集中控制单元331控制比较单元332主要进行如下两方面的比较操作。

一方面，对响应的opcode进行分析，若当前响应的opcode标识是RetryAck类型，则使能计数器加一信号（cnt_up）控制计数单元（retry_cntr）333进行加一操作。此时，集中控制单元331会根据响应的TxnID发起对请求存储区340的遍历读操作，根据TxnID找到被retry的请求信息，并将该请求信息写入重试请求存储区350中暂存，同步将请求存储区340中的数据做废掉（删除）。若当前响应的opcode标识不是RetryAck类型，直接将请求存储区340中的数据做废掉。

另一方面，该模块在每次接收到请求时，会对请求存储区340中的addr与重试请求存储区350中的addr进行比较，若接收到的请求addr与重试请求的addr一致，代表之前被retry的请求将会被处理，此类请求是不能再被retry的，因此可使能计数器减一信号（cnt_down）控制计数单元333进行减一操作，同时做废掉该请求在请求存储区340中与重试请求存储区350中的数据。

计数单元333可以在使能信号cnt_up与cnt_down的作用下进行实时计数，并产生控制信号。当该计数值达到拥塞上限（block_hi）时，可以使用暂停控制信号（req_stop）来暂停上游master模块继续发出请求。随着请求被下游slave处理，当计数值到达拥塞下限（block_lo）时，使用运行控制信号（req_run）来恢复上游master模块发出请求的操作。通过上述动态管理，可以避免在事务大量拥塞时的功耗浪费。

需要说明的是，本申请实施例可以应用于使用CHI协议进行事务传输的场景，尤其是上下游时钟频率相差较大的情况，若上游持续发出请求并被拥塞处理，会加剧系统的功耗。本申请实施例可以实时监控事务的传输情况，在产生拥塞时进行动态调整，通过暂停/恢复的方式来进行请求的传输控制，从而达到降低功耗的目的。

图4为本申请实施例提供的一种计算设备的结构示意图。计算设备400可以包括处理器系统410，处理器系统410可以为前文所述的任意一种处理器系统。

上文结合图1至图4详细描述了本申请的装置实施例，下面结合图5详细描述本申请的方法实施例。应理解，方法实施例的描述与装置实施例的描述相互对应，因此，未详细描述的部分可以参见前面装置实施例。

图5为本申请实施例提供的一种处理请求的方法的流程示意图。所述处理请求的方法应用于处理器系统，所述处理器系统包括第一模块和第二模块，所述第二模块通过支持重试机制的总线协议与所述第一模块通信连接。

参见图5，方法500可以包括步骤S510和步骤S520。

在步骤S510，第一模块向第二模块发送一个或多个请求。

在步骤S520，基于第二模块针对一个或多个请求反馈的重试响应，第一模块确定针对第二模块的请求发送策略。

可选地，所述请求发送策略用于降低向所述第二模块发送请求的频率。

可选地，所述请求发送策略包括以下中的一种或多种：暂停向所述第二模块发送请求；以及暂停处理器核的数据预取操作。

可选地，所述第一模块基于第一时钟频率工作，所述第二模块基于第二时钟频率工作，且所述第一时钟频率高于所述第二时钟频率。

可选地，所述第一模块基于以下中的一种或多种确定所述请求发送策略：所述第二模块反馈的重试响应的数量；以及所述第二模块反馈的重试响应对应的请求的类型。

可选地，所述处理器系统还包括计数器，所述计数器用于统计所述第二模块反馈的重试响应的数量。

可选地，所述计数器设置在所述第一模块上。

可选地，所述第一模块还用于调整所述第一模块的流水线的调度策略。

可选地，所述调度策略包括：延后处理所述重试响应对应的请求所关联的指令。

可选地，所述总线协议为一致性集线器接口协议。

应理解，在本申请实施例中，“与A相应的B”表示B与A相关联，根据A可以确定B。但还应理解，根据A确定B并不意味着仅仅根据A确定B，还可以根据A和/或其它信息确定B。

应理解，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线（例如同轴电缆、光纤、数字用户线（digital subscriber Line，DSL））或无线（例如红外、无线、微波等）方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够读取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，（例如，软盘、硬盘、磁带）、光介质（例如，数字通用光盘（digital video disc，DVD））或者半导体介质（例如，固态硬盘（solid state disk，SSD））等。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims

1.一种处理器系统，其特征在于，包括：

第一模块；

第二模块，通过支持重试机制的总线协议与所述第一模块通信连接；

其中，所述第一模块用于执行以下操作：

向所述第二模块发送一个或多个请求；

基于所述第二模块针对所述一个或多个请求反馈的重试响应，确定针对所述第二模块的请求发送策略。

2.根据权利要求1所述的处理器系统，其特征在于，所述请求发送策略用于降低向所述第二模块发送请求的频率。

3.根据权利要求2所述的处理器系统，其特征在于，所述请求发送策略包括以下中的一种或多种：

暂停向所述第二模块发送请求；以及

暂停处理器核的数据预取操作。

4.根据权利要求1所述的处理器系统，其特征在于，所述第一模块基于第一时钟频率工作，所述第二模块基于第二时钟频率工作，且所述第一时钟频率高于所述第二时钟频率。

5.根据权利要求1所述的处理器系统，其特征在于，所述第一模块基于以下中的一种或多种确定所述请求发送策略：

所述第二模块反馈的重试响应的数量；以及

所述第二模块反馈的重试响应对应的请求的类型。

6.根据权利要求5所述的处理器系统，其特征在于，所述处理器系统还包括：

计数器，用于统计所述第二模块反馈的重试响应的数量。

7.根据权利要求6所述的处理器系统，其特征在于，所述计数器设置在所述第一模块上。

8.根据权利要求1所述的处理器系统，其特征在于，所述第一模块还用于：

调整所述第一模块的流水线的调度策略。

9.根据权利要求8所述的处理器系统，其特征在于，所述调度策略包括：延后处理所述重试响应对应的请求所关联的指令。

10.根据权利要求1所述的处理器系统，其特征在于，所述总线协议为一致性集线器接口协议。

11.一种处理请求的方法，其特征在于，所述处理请求的方法应用于处理器系统，所述处理器系统包括第一模块和第二模块，所述第二模块通过支持重试机制的总线协议与所述第一模块通信连接，所述方法包括：

所述第一模块向所述第二模块发送一个或多个请求；

基于所述第二模块针对所述一个或多个请求反馈的重试响应，所述第一模块确定针对所述第二模块的请求发送策略。

12.根据权利要求11所述的方法，其特征在于，所述请求发送策略用于降低向所述第二模块发送请求的频率。

13.根据权利要求12所述的方法，其特征在于，所述请求发送策略包括以下中的一种或多种：

暂停向所述第二模块发送请求；以及

暂停处理器核的数据预取操作。

14.根据权利要求11所述的方法，其特征在于，所述第一模块基于第一时钟频率工作，所述第二模块基于第二时钟频率工作，且所述第一时钟频率高于所述第二时钟频率。

15.根据权利要求11所述的方法，其特征在于，所述第一模块基于以下中的一种或多种确定所述请求发送策略：

所述第二模块反馈的重试响应的数量；以及

所述第二模块反馈的重试响应对应的请求的类型。

16.根据权利要求15所述的方法，其特征在于，所述处理器系统还包括计数器，所述计数器用于统计所述第二模块反馈的重试响应的数量。

17.根据权利要求16所述的方法，其特征在于，所述计数器设置在所述第一模块上。

18.根据权利要求11所述的方法，其特征在于，所述第一模块还用于调整所述第一模块的流水线的调度策略。

19.根据权利要求18所述的方法，其特征在于，所述调度策略包括：延后处理所述重试响应对应的请求所关联的指令。

20.根据权利要求11所述的方法，其特征在于，所述总线协议为一致性集线器接口协议。

21.一种计算设备，其特征在于，所述计算设备包括如权利要求1-10中任意一项所述的处理器系统。