CN106250348A - 一种基于gpu访存特性的异构多核架构缓存管理方法 - Google Patents

Abstract

本发明公开一种基于GPU访存特性的异构多核架构缓存管理方法，首先进行消息的区分，对来自CPU和GPU核心L1 Cache的不同消息进行不同的处理；如果GPU L1 Cache请求的数据块在L2 Cache中，直接读取该数据块返回给GPU L1 Cache；如果请求的数据块不在L2 Cache中，但L2 Cache中有空闲，则从MEMORY中读取数据写入到L2 Cache中，并将数据返回给GPU L1 Cache；如果请求的数据块不在L2 Cache中，且L2 Cache中没有空闲，则直接发送请求消息给MEMORY，从MEMORY中读取消息，返回给GPU L1 Cache，并将该数据写入相应L1 Cache。本发明的方法减少了GPU应用程序所需数据在L2 Cache中的替换，将多余的空间留给CPU程序使用，提升了CPU应用程序的性能，从而提升异构多核系统的整体性能。

Description

一种基于GPU访存特性的异构多核架构缓存管理方法

技术领域

本发明属于计算机体系缓存系统结构领域，尤其涉及一种基于GPU访存特性的异构多核架构缓存管理方法。

背景技术

多核处理器在一个芯片上拥有多个功能相同的处理器核心，其主要通过主频和每时钟周期所执行的指令数来提高性能，并且多核处理器能很好的平衡功耗与性能的关系。但是，提升处理器的性能仅仅通过增加同种内核的方法存在一定的局限性，在系统达到极限值之后，处理器性能的提高就无法再随着内核数量的增加来实现了，这遵循著名的Amdahl定律。研究人员开始研究能替换同构CPU芯片的异构CPU芯片。

异构多核处理器(HMP-Heterogeneous Multi-core Processor)将具有不同计算能力的处理器融合到一起，被广泛应用于航空航天、工业控制、仪器仪表等行业，以满足系统性能需求，降低功耗和成本。HMP由于集成了不同特点和性能的处理器核，可将不同类型的计算任务分配到不同类型的处理器核上并行处理，比如，快速复杂的核可以执行串行代码部分，而较简单的核则能并行处理数字，从而为不同需求的应用提供更加灵活、高效的处理机制，满足多种应用环境对系统实时性、功耗、可靠性和成本的要求，成为当今研究的热点。事实也证明在浮点运算、并行计算等方面，GPU可以提供数十倍乃至于上百倍于CPU的性能。

异构多核处理器上CPU和GPU的集成，对共享片上资源提出新的挑战。最后一级共享Cache(The shared last-level Cache，简称共享LLC)是影响性能的最重要的共享资源。随着处理器和存储器之间速度差距的不断扩大，最后一级高速缓存对处理器访存性能的影响也将逐渐增大，最后一级高速缓存的重要性日益凸显。对最后一级高速缓存进行有效管理，提高最后一级高速缓存利用率对于优化计算机系统的整体性能具有重要的意义。

GPU的核心数量非常多，这和CPU有本质的区别，一般GPU都内置了数百个内核，甚至上千个，GPU的工作原理就是并行计算，在并行处理特定数据的时候，GPU比CPU高效非常多。当前的缓存管理策略下，当CPU应用程序和GPU应用程序共同执行时，会争夺共享LLC，导致CPU应用程序对于共享LLC的访问会明显降低，对于很多CPU应用程序而言，减少了对共享LLC的访问会明显降低系统性能。而GPU应用程序有足够的线程级并行(TLP)，可以在一定程度上容忍增加的内存访问延迟，因而对其性能影响不是很大。因此，在异构多核系统中，共享LLC的管理对于系统性能和功耗的影响至关重要。此时，一个合理高效的缓存管理策略对于提升处理器性能和降低功耗十分必要。

发明内容

本发明要解决的技术问题是，提供一种基于GPU访存特性的异构多核架构缓存管理方法，综合分析CPU应用程序和GPU应用程序的特征，考虑到在LLC的访问上，GPU应用程序占据了大量LLC空间，所以，通过限制GPU应用程序对LLC的访问，转而访问内存，来实现CPU和GPU应用程序对共享缓存访问的分离，缓解CPU应用程序和GPU应用程序对共享缓存的争夺，从整体上提升系统性能。

为达到上述目的，本发明采用以下技术方案。

一种基于GPU访存特性的异构多核架构缓存管理方法，异构多核架构由若干个CPU和GPU内核组成，所述CPU和GPU拥有各自的L1 Cache，共同访问L2 Cache，L1 Cache由L1Cache Controller来控制，L2 Cache由L2 Cache Controller来控制，该方法包括如下步骤：

步骤1、区分GPU核心和CPU核心的L1 Cache Controller；

步骤2、跟踪消息传递过程，在每个消息上添加标志位来标记该消息的来源；

步骤3、在L2 Cache Controller上进行消息类型判断，对来自CPU和GPU的L1Cache请求做不同处理；

步骤4、在Directory Controller中判断，如果是该消息请求者，类型为L1 Cache，则触发事件执行，赋其消息请求者为L1 Cache，读取内存数据；

步骤5、在Directory Controller的内存消息响应队列中判断，如果消息原始请求者类型为L1 Cache，则触发相应事件，将该数据发送给L1 Cache Controller；

步骤6、在L1 Cache Controller中接收到Directory Controller发回的数据时，将该数据块写入L1 Cache，并将数据发送给需要该数据的GPU核心；

步骤7、当L1 Cache Controller进行替换或写回时，如果该数据块在L2 Cache中，直接替换，并进行数据状态及shares的改变，但如果不在L2 Cache中时，则将其发送给Directory Controller，进行数据替换及相应操作。

作为优选，步骤S3包括以下步骤：

步骤3.1、在L2 Cache的请求缓冲队列L1RequestToL2Cache中，识别不同消息，判断该消息标记位，如果是来自于GPU核心的L1 Cache Controller，首先判断L2中是否包含所请求的数据块，如果包含，直接根据消息类型执行相应的动作，将所需要的数据发送给请求者；

步骤3.2、如果L2 Cache Controller中不包含该请求所需要的数据块，且L2Cache中仍然有空间来存放数据，则触发响应事件去取得该数据存入L2Cache中，之后将该数据发送给L1请求者；

步骤3.3、如果L2 Cache Controller中不包含该请求者所需要的数据，且没有多余空间来存放数据，则直接发送请求给MEMORY，请求获得相应的数据，消息传递过程中，将请求者赋值为原始消息请求者。

与现有技术相比，本发明具有以下优点：

分析CPU应用程序和GPU应用程序的特点，考虑到GPU应用程序有足够的线程级并行(TLP)，可以在一定程度上容忍增加的内存访问延迟。所以，为限制GPU应用程序对LLC的访问，可通过减少GPU应用程序在LLC中的数据替换，而从MEMORY中直接读取数据来实现CPU和GPU应用程序对缓存访问的分离，缓解CPU应用程序和GPU应用程序对共享缓存的争夺。通过本方法可在CPU应用程序和GPU应用程序共同执行情况下，提高CPU应用程序对LLC的使用率，达到提高异构多核系统整体性能的目的。

附图说明

为使本发明的目的，方案更加通俗易懂，下面将结合附图对本发明进一步说明。

图1为异构多核处理器系统的结构图，该异构多核处理器由2个CPU核心和4个GPU核心组成，每个核心都有自己的私有Cache。这些核心共享LLC和DRAM(MEMORY)，并通过片上互连网络模块进行通信；

图2为SLICC运行机制图；

图3为GPU访存过程流程图。

具体实施方式

为使本发明的目的，技术方案和优点更加清楚明白，下文中将结合附图对本发明的实施例进行详细说明。

本发明提供一种基于GPU访存特性的异构多核架构缓存管理方法，异构多核架构由若干个CPU和GPU内核组成，每个核心都有自己的私有Cache。这些核心共享LLC和DRAM(MEMORY)，并通过片上互连网络模块进行通信。本发明依赖MESI_Two_Level缓存一致性协议，该协议中CPU和GPU拥有各自的L1 Cache，共同访问L2 Cache，如图1所示。

本发明方法首先进行消息的区分，对来自CPU和GPU核心L1 Cache的不同消息进行不同的处理。如果GPU L1 Cache请求的数据块在L2 Cache中，直接读取该数据块返回给GPUL1 Cache；如果请求的数据块不在L2 Cache中，但L2 Cache中有空闲，则从MEMORY中读取数据写入到L2 Cache中，并将数据返回给GPU L1 Cache；如果请求的数据块不在L2 Cache中，且L2 Cache中没有空闲，则直接发送请求消息给MEMORY，从MEMORY中读取消息，返回给GPUL1 Cache，并将该数据写入相应L1 Cache。该方法减少了GPU应用程序所需数据在L2 Cache中的替换，将多余的空间留给CPU程序使用。提升了CPU应用程序的性能，从而提升异构多核系统的整体性能。

本发明实施例所涉及的是基于GPU访存特性的异构多核架构缓存管理方法，以一个具有两个CPU核心、四个GPU核心，每个核心均拥有各自的L1 Cache但共享一个L2 Cache的异构处理器为例。运行的CPU测试程序是单线程的SPEC CPU2006，GPU应用程序为Rodinia。每一个workload由一个CPU测试程序和一个GPU应用程序组成。在模拟器中，使用SLICC(specification language for implementing cache coherence)脚本语言来描述一致性协议。如图2所示，为SLICC运行机制图。具体步骤如下：

步骤1，区分GPU和CPU的L1 Cache Controller，自定义标记给每一个Cache编号，区分L1 Cache是属于CPU核心还是GPU核心。

运行一个workload group(2个测试程序)，一个CPU核上运行一个CPU测试程序SPEC2006，另一个CPU核引导GPU应用程序rodinia运行在4个GPU核心上。因为每个核心独有各自的L1 Cache，总计有六个。所以为了区分这六个L1 Cache，在L1 Cache Controller上添加标记cpuorgpu。初始化时为这六个L1 Cache赋不同的值。

步骤2，跟踪消息传递过程，在每个消息上添加标志位来标记该消息的来源。

从L1 Cache Controller开始，在执行相应action时，会往输出消息队列中添加消息，为能在L2 Cache Controller中区分来自不同L1 Cache Controller的消息，需在消息上添加标记ContextIDxx。在消息的定义中添加属性ContextIDxx。当插入消息进入消息队列时，为该属性ContextIDxx赋值。L2 Cache Controller中同理。

步骤3，当L1 Cache Controller消息到达L2 Cache Controller时，在端口L1RequestL2Network_in上进行消息类型判断，对来自CPU和GPU核心的L1 Cache请求做不同的处理，GPU访存过程如图3所示。

步骤3.1，在L2 Cache Controller的请求缓冲队列L1RequestToL2Cache中，识别不同消息。判断该消息标记位(in_msg.ContextIDxx)，如果该消息是来自CPU核心的L1Cache Controller，则不做特殊处理。但如果该消息是来自于GPU核心的L1 CacheController，必须对其进行分类处理。首先判断L2 Cache Controller中是否包含所请求的数据块cache_entry，可用语句is_valid(cache_entry)实现，如果包含，直接根据消息类型(in_msg.Type)执行相应的动作，将所需要的数据发送给请求者。

步骤3.2，如果L2 Cache Controller中不包含该请求所需要的数据块，但L2中仍然有空间来存放数据，则触发响应事件取得该数据存入L2中。之后将该数据发送给L1请求者。

步骤3.3，如果L2 Cache Controller中不包含该请求者所需要的数据，且没有多余空间来存放数据，一般情况下，此时需要进行数据的替换，但考虑到如果该数据块为CPU核心所需要的，将其替换后会延缓单线程CPU应用程序的执行，而且考虑到GPU应用程序的多并发线程的特性，延缓该线程的运行仍可执行其他线程。故对于GPU应用程序所需的数据不在L2 Cache Controller中的情况，不执行替换操作，而是直接发送请求给MEMORY，请求获得相应的数据块。此时，需要自定义Event实现该操作。在实现过程中，因L1 CacheController发送的不同消息类型，如GETS、GET_INSTR、GETX等。所以对于不同的消息类型，要定义不同的Event。而且要考虑到当前地址的数据块的状态。因为不做数据的替换，所以，也不进行状态的转变。不同的Event，但都要执行从MEMORY读取数据的操作。自定义该操作，将输出的请求消息发送者赋值为输入的请求消息发送者(其消息请求者类型为L1 Cache)。

步骤4，在SLICC/Ruby下，Directory Controller也就是Memory Controller。异构多核架构下，存储模型为Ruby。故对MEMORY的请求是在Directory Controller中控制的。在Directory Controller的端口requestNetwork_in中判断，依次检查requestToDir消息缓冲队列中的每条请求消息，如果是该消息请求者类型为L2 Cache，不做特殊处理。如果该消息请求者类型为L1 Cache，则需定义Event，实现L1 Cache Controller对MEMORY的请求。在该Event中触发内存读取请求时，需要将消息的原始请求者赋值为L1 Cache，读取内存数据。

步骤5，在Directory Controller的端口memQueue_in中，对内存消息响应队列responseFromMemory中的消息依次进行判断，如果消息原始请求者类型为L1 Cache，仍需自定义Event，自定义action，将该数据块发送给L1 Cache Controller。发送的消息类型不同于发送给L2 Cache Controller的。

步骤6，在L1 Cache Controller中接收到Directory Controller发回的数据时，将该数据块写入L1 Cache，并将数据发送给需要该数据的GPU核心。

步骤7，当L1 Cache Controller进行替换或写回时，如果该数据块在L2 Cache中，直接替换，并进行数据状态及shares的改变，但如果不在L2 Cache中时，则将其发送给Directory Controller，进行数据替换及相应操作。

本发明的一种基于GPU访存特性的异构多核架构缓存管理方法，异构多核架构下，CPU应用程序和GPU应用程序共同执行，综合分析CPU应用程序和GPU应用程序的特征，当两种程序同时执行时，会争夺共享LLC，GPU应用程序将占据大量LLC空间，导致CPU应用程序对共享LLC的访问明显降低，严重影响CPU应用程序的性能。考虑到GPU应用程序有足够的线程级并行(TLP)，可以在一定程度上容忍增加的内存访问延迟。所以，为限制GPU应用程序对LLC的访问，可通过减少GPU应用程序在LLC中的数据替换，而从MEMORY中直接读取数据来实现CPU和GPU应用程序对缓存访问的分离，缓解CPU应用程序和GPU应用程序对共享缓存的争夺，从而达到从整体上提升系统性能。

以上实施例仅为本发明的示例性实施例，不用于限制本发明，本发明的保护范围由权利要求书限定。本领域技术人员可以在本发明的实质和保护范围内，对本发明做出各种修改或等同替换，这种修改或等同替换也应视为落在本发明的保护范围内。

Claims (2)

1.一种基于GPU访存特性的异构多核架构缓存管理方法，其特征在于，异构多核架构由若干个CPU和GPU内核组成，所述CPU和GPU拥有各自的L1 Cache，共同访问L2 Cache，L1Cache由L1 Cache Controller来控制，L2 Cache由L2 Cache Controller来控制，该方法包括如下步骤：

步骤1、区分GPU核心和CPU核心的L1 Cache Controller；

步骤2、跟踪消息传递过程，在每个消息上添加标志位来标记该消息的来源；

步骤3、在L2 Cache Controller上进行消息类型判断，对来自CPU和GPU的L1Cache请求做不同处理；

步骤4、在Directory Controller中判断，如果是该消息请求者，类型为L1 Cache，则触发事件执行，赋其消息请求者为L1 Cache，读取内存数据；

步骤5、在Directory Controller的内存消息响应队列中判断，如果消息原始请求者类型为L1 Cache，则触发相应事件，将该数据发送给L1 Cache Controller；

步骤6、在L1 Cache Controller中接收到Directory Controller发回的数据时，将该数据块写入L1Cache，并将数据发送给需要该数据的GPU核心；

步骤7、当L1 Cache Controller进行替换或写回时，如果该数据块在L2 Cache中，直接替换，并进行数据状态及shares的改变，但如果不在L2 Cache中时，则将其发送给Directory Controller，进行数据替换及相应操作。

2.如权利要求1所述的基于GPU访存特性的异构多核架构缓存管理方法，其特征在于，步骤S3包括以下步骤：

步骤3.1、在L2 Cache的请求缓冲队列L1RequestToL2Cache中，识别不同消息，判断该消息标记位，如果是来自于GPU核心的L1 Cache Controller，首先判断L2中是否包含所请求的数据块，如果包含，直接根据消息类型执行相应的动作，将所需要的数据发送给请求者；

步骤3.2、如果L2 Cache Controller中不包含该请求所需要的数据块，且L2 Cache中仍然有空间来存放数据，则触发响应事件去取得该数据存入L2Cache中，之后将该数据发送给L1请求者；

步骤3.3、如果L2 Cache Controller中不包含该请求者所需要的数据，且没有多余空间来存放数据，则直接发送请求给MEMORY，请求获得相应的数据，消息传递过程中，将请求者赋值为原始消息请求者。