首页 > 英文翻译

inclusive

更新时间:2022-12-28 12:28:34 阅读：评论：0

2022年12月28日发(作者：席慕容青春)

摘要

高速缓存是高性能处理器中提高访存速度的重要技术，其对处理器性能的影响至关重要。本论

文主要针对基于包容式高速缓存结构的多核处理器中，多核共享的最下级缓存不清楚其上层缓存的

使用情况而导致下级缓存将上级的常用数据无效掉的问题，提出一种感应上级的最近最少使用

(LRU,LeastRecentlyUd）替换策略，将上级高速缓存(Cache)的局部性信息发送给下级Cache，下

级Cache在数据替换的时候，结合上级Cache和本级Cache综合的局部性信息进行替换，避免上述

错误的无效掉上级Cache常用数据的情况。从而提高处理器执行效率和整体性能。

在上述理论基础上，以GEM5处理器模拟器为设计与测试平台，修改缓存模型中最外层高速缓

存(LLC,LastLevelCache)的替换策略的代码。具体方法主要为，在共享的LLC上加入upperAccess

标志位，以upperAccess标志位的状态为上级Cache数据使用情况的判断依据，在LLC需要做出替

换决定时优化LLC高速缓存行(Cacheline)的替换顺序，尽量避免上层缓存的常用数据被替换掉，从

而完成感应上级的LRU替换策略的加入，并以此减少二级缓存(L2Cache)和更上级Cache出现包含

式受害者(InlusuveVictim)现象的次数。

在加入感应上级的LRU替换策略的模拟器模型中运行SPECCPU2006测试集进行验证。以L2

和L3Cache的每千条指令的未命中数据(MPKI,MissperKiloInstruction)和每周期指令数(IPC,Instruc-

tionspercycle)数据为切入点，对比优化前后的缓存替换策略对系统整体性能的影响。对比多个测试

项目的结果，优化后单核测试下的IPC平均提升1.35%，L2Cache的MPKI平均降低1.5%。优化后

多核测试的IPC数据平均提升3.83%，L3cache的MPKI平均降低5.0%。验证了感应上级的LRU替

换策略对解决InclusiveVictim问题有所帮助，并提高了Cache模型的整体性能。

关键词：高速缓存；感应上级；替换策略；GEM5；缓存未命中；每周期指令

Abstract

Cacheisanimportanttechnologyforincreasingthespeedofmemoryaccessinhigh-performancepro-

cessors,esismainlyfocusonthemulti-core

estlevelcacheofmulti-coresharingisnotclear

abouttheuoftheupperlevelcache,whichleadstothelowerlevelcacheandinvalidatestheuful

replacementstrategyndsthelocalityinformationoftheupper-level

chelineinthethelower-levelcacheisreplaced,thelocal-levelinfor-

mationoftheupper-levelcacheandthelocal-levelcacheisreplaced,toavoidtheabove-mentionederrors

yimprovingprocessorexecutionefficiency

andoverallperformance.

Badontheabovetheory,theGEM5processorsimulatorisudasthedesignandtestplatformto

modifythecodeofthereplacementstrategyoftheLLC(LastLevelCache)cific

methodismainlytoaddtheupperAccessflagbittothesharedLLC,thestateoftheupperAccessflagbitis

thejudgmentbasisoftheupper-levelcachedatausage,andoptimizetheLLCcachelinereplaceorderwhen

theLLCneedstomakeareplacementdecision,toavoidtheufuldataoftheuppercachebeingreplaced,

thuscompletingtheinductionofthesuperiorLRUreplacementstrategy,andtherebyreducingthenumberof

timestheinlusuvevictimphenomenonoftheL2cacheandtheupper-levelcache.

RunningtheSPECCPU2006testtsinthesimulatormodeltoverifythensingsuperiorLRUre-

themissnumberandIPCofL2andL3cacheastheentrypoint,theimpactofthe

cachereplacementstrategybeforeandafteroptimizationontheoverallperformanceofthesystemiscom-

ultsofmultipletestprojectswerecompared,theIPCundertheoptimizedsingle-coretestin-

creadbyanaverageof1.35%,andtheL2cacheMPKIdecreadbyanaverageof1.5%.Afteroptimization,

theIPCdataofthemulti-coretestincreadby3.83%onaverage,andtheL3cacheMPKIdecreadby5.0%

rifiedthatthensingsuperiorLRUreplacementstrategyhelpstosolvetheinclusive

victimproblemandimprovestheoverallperformanceofthecachemodel.

Keywords:Cache;HigherLevelSen;ReplacementPolicy;GEM5;CacheMiss;IPC

III

摘要.......................................................................................................................................................I

ABSTRACT.............................................................................................................................................II

目录...................................................................................................................................................III

第一章绪论.............................................................................................................................................1

1.1背景与意义....................................................................................................................................1

1.1.1研究背景.................................................................................................................................1

1.1.2研究意义.................................................................................................................................1

1.2国内外研究现状综述......................................................................................................................2

1.3主要内容与设计指标......................................................................................................................4

1.3.1论文主要研究内容..................................................................................................................4

1.3.2设计指标.................................................................................................................................4

1.4论文组织框架.................................................................................................................................4

第二章处理器高速缓存架构....................................................................................................................7

2.1高性能处理器的CACHE-MEMORY结构............................................................................................7

2.2高速缓存包含策略........................................................................................................................10

2.3高速缓存的替换策略.....................................................................................................................11

2.4INCLUSIVEVICTIM原因分析............................................................................................................12

2.5本章小结......................................................................................................................................15

第三章GEM5模拟器的介绍与分析......................................................................................................17

3.1GEM5的关键特性........................................................................................................................17

3.2GEM5进行模拟仿真的基本机制..................................................................................................18

3.2.1ClassEvent...........................................................................................................................18

3.2.2ClassEventWrapper.............................................................................................................18

3.2.3ClassEventQueue................................................................................................................18

3.2.4ClassEventManager.............................................................................................................19

3.3多级CACHE的互联.......................................................................................................................19

3.3.1不同存储部件信息的载体：ClassPacket.............................................................................20

3.3.2连接不同部件的关键：Port类..............................................................................................22

3.3.3ClassPacketQueue：关联Port和Event的关键.................................................................27

3.3.4连接不同部件的BUS：ClassCoherentXbar.......................................................................28

3.4单级CACHE结构图.......................................................................................................................31

3.4.1组相联cache：ClassLRU...................................................................................................32

3.4.2MSHRQueueMissQueue/writebuffer.................................................................................34

3.4.3主要Port对应的ReceiveEvent的处理...............................................................................36

3.5本章小结......................................................................................................................................42

第四章缓存替换策略的优化..................................................................................................................43

4.1缓存性能的优化方案....................................................................................................................43

4.2缓存性能优化的实现....................................................................................................................44

4.2.1下级cache增加信息记录上级cache的使用情况................................................................44

东南大学工程硕士学位论文

4.2.2上级cache增加替换Cleandata告知下级cache的机制....................................................45

4.2.3支持多级cache间的包含机制..............................................................................................48

4.2.4替换算法的修改实现.............................................................................................................50

4.3本章小结......................................................................................................................................51

第五章优化替换策略后的测试结果与分析............................................................................................53

5.1实验环境......................................................................................................................................53

5.1.1模拟器中的cache结构.........................................................................................................53

5.1.2实验环境与测试集................................................................................................................54

5.1.3衡量cache性能和效率的主要指标......................................................................................54

5.2性能测试结果对比与分析.............................................................................................................55

5.2.1单核测试及分析....................................................................................................................55

5.2.2四核测试及分析....................................................................................................................58

5.2.3测试结果与预期指标对比.....................................................................................................61

5.3本章小结.......................................................................................................................................62

第六章总结与展望................................................................................................................................63

6.1总结.............................................................................................................................................63

6.2展望.............................................................................................................................................63

参考文献................................................................................................................................................65

致谢........................................................................................................................................................67

第一章绪论

作者在攻读硕士研究生期间，作为设计人员参与了基于IBMPOWER架构的某款高性能服务

器处理器项目。在项目中发现包含式缓存（InclusiveCache）存在低级缓存错误牺牲（Victim）上

级缓存中的常用数据的情况。为了解决上述问题，本文提出一种多核处理器多级缓存的替换策略的

优化方案，旨在提高处理器整体性能和效率，使得Inclusivecache克服性能不如其他缓存结构的缺

点。更好的读写效率加上其在一致性上的优点，进一步巩固Inclusivecache应用在多核高性能处理

器上的优势。本文研究并模拟了基于64位多核多线程处理器的Inclusive结构三级缓存。

1.1背景与意义

1.1.1研究背景

1971年秋天，美国德州仪器公司向业界发布了第一款4位嵌入式微处理器TMS1000，标志着

人类正式进入了微处理器的新时代。此后的40多年里，微处理器的研究飞速发展，微处理器已经

成为当今迅速发展的信息化社会中最重要的技术支撑之一，随着云计算、云存储、流媒体、人工智

能等前沿领域的不断探索，对处理器性能的要求水涨船高，也对处理器的效率、工艺、功耗、可扩

展性提出了更高的要求[1]。此外，随着这些年我国集成电路与微电子行业的高速发展，对自主研

发、自主可控的需求也越来越强。

本文作者所在的公司从事基于IBMPOWER平台的高性能处理器的设计研发工作。在实际项目

中已经通过模拟器建模，并以模拟器模型为基础运行了一些测试项目。本次课题设计将采用类似方

式，通过在GEM5平台上对业界主流的高性能处理器缓存微架构进行建模，并且针对集中缓存替

换算法的模型进行测试，验证它们对处理器性能的影响，并加以比较和分析。

1.1.2研究意义

相比于国外微处理器行业40多年来的稳步发展，我国集成电路（IC,IntegratedCircuit）行业经

过近些年的大力发展虽有长足进步，但是在高性能处理器领域，受累于起步较晚和长期的技术壁垒

等原因，依然缺乏拥有行业领先技术的高端产品。随着摩尔定律逐渐开始退出历史舞台，处理器行

业的热点已经从单纯的工作频率和晶体管数量的提升转向了多核心、多线程协同运作。这对基础相

对薄弱的我国IC行业来说，是一个迎头赶上的好机会。此外，当今科技行业的焦点集中在云计

算、超高清视频、物联网、人工智能等领域，它们无一例外的都对处理能力有着极高的要求，而影

响处理器性能的一个关键因素就在高速缓存的效率。在微处理器设计中，如何给处理器提供充足、

东南大学工程硕士学位论文

稳定的指令和数据流是一个永恒的话题。但是就近二十几年计算机的发展情况来看，处理器和主存

之间在速度上的差距却越来越大[2]。

通过目录的方式记录上级Cache是否存在对应数据块的副本，同时此目录也实现了Cache的

一致性。基于CMP中包含式高速缓存(InclusiveCache)一致性方面的优势和性能方面的劣势共存的

特点，一旦缩小了Inclusivecache在性能方面的劣势，便能有效解决缓存对多核处理器的性能瓶颈

[3]。

1.2国内外研究现状综述

1971年，在美国德州仪器公司的TMS1000问世后不久，更最广为人知的微处理器4004在

Intel公司诞生了。这一年也成为了人类历史上的微处理器元年，比起如今的处理器，TMS1000和

4004这样的4位处理器相比之下显得很是可怜，它们只由数千个晶体管组成，指令也非常简单，

速度更是不值一提。但在之后的近50年的发展历程中，计算机的体系结构经历了无数次的重大突

破，经历了一系列由简单到复杂的过程。流水线技术、动态调度技术、高速缓存技术、向量机技

术、多核技术被广泛使用，性能不断登上新的高峰[4]。然而推陈出新、不断前进是这个行业永恒的

宗旨[5][6]。作为行业翘楚，Intel、AMD等公司每隔1到2年就会推出新一代高性能处理器产品。而

在缓存的设计上，也是不尽相同。

2017年7月，Intel公司发布了消费级最高端的Skylake-X内核，采用Intel14nm工艺制造，提

供6-18个不同数量的CPU核心，每个核心有2个逻辑线程，最高可以提供单片36线程，并搭配

重新设计、更加平衡的智能缓存系统。在缓存架构方面，Skylake-X重新设计了更加平衡的缓存系

统，三级缓存（L3）容量比上一代产品减小，每个核心从2.5MB减小到1.375MB，这主要是因为

三级缓存从包含式(Inclusive)变成了非包含式(non-Inclusive)。作为弥补，每个核心独有的二级缓存

（L2）则从256KB增大到1MB，而一级缓存（L1）与L2之间，依然是inclusive的设计[7]。

作为Intel在X86市场最强劲的对手，AMD在2017年初推出了全新的Zen架构处理器，试图

与Intel在高端市场产生冲击。Zen在架构设计方面相对上一代产品变化很大，大幅改良了运算单元

及缓存架构，加入了SMT同步多线程技术，整体性能相对上一代产品提升达到50%以上。为了提

升处理器数据吞吐量，AMDZen微架构采用全新的cachesubsystem设计，一级指令缓存（L1

Icache）不再由两个核心共享，变回独立的64KBIcache，同时从2-way的组相连提升到4-way，以

提高Icache的命中率。此外一级数据缓存（Dcache）相比上代产品加倍到每个核独享32KB和8-

way组相连。每个核拥有512KB、8-Way组相连的L2，并且放弃沿用十几年的Exclusive缓存策

略，改为和业界主流同样的inclusive策略。Zen的L3设计比较独特，每4个CPU核心共享16-

第一章绪论

way8MBL3缓存[8]。

虽然国家正在大力扶持集成电路行业企业的发展，但由于技术积累的薄弱和资金投入周期依然

较短等原因，目前国内的处理器设计水平和国外行业龙头的差距依然非常大的差距。以最为知名的

龙芯为例，2015年推出的GS464微架构据称达到接近IntelIvyBridge的性能，在仅使用40nm工

艺的前提下，这个成绩还是相当不错的。在本文关注的缓存方面，四核的龙芯GS464每个核的

Dcache和Icache都为64KB、4-way组相连，但与业界普遍的设计不同，在Icache下面，还有一道

独立缓存系统，龙芯组将它称之为VictimCache。这个VictimCache有256KB之大，更像是Icache

的私有L2,。GS464真正的L2为16-way、256KB，使用伪LRU替换算法。L3每个核独享2MB、

16路组相连的L3cache[9]。除了多出来的VictimCache，缓存的数据和当时的业界主流处理器还是

比较接近的。

表1.1业界主流最新高性能处理器cache结构

DcacheIcacheL2L3(percore)L1-L2L2-L3

Skylake-

32KB

8-way

32KB

8-way

1MB

16-way

1.375MB

11-way

inclusivenon-inclusive

Zen32KB

8-way

64KB

4-way

512KB

8-way

2MB

16-way

inclusiveexclusive

龙芯

64KB

4-way

64KB

4-way

256KB

16-way

2MB

16-way

exclusive

未知

由上表1.1所示的国内外最新的处理器缓存设计的情况看，由于面积和成本的制约，高性能处

理器的缓存已经基本达到阶段性的临界点，在工艺和架构出现新的突破之前，缓存的大小和结构已

经不太可能有很大的变化。因此如何在现有微架构上提升缓存的命中率、提高处理器的访问效率才

是当前的研究和设计的主要攻坚点。

对于本文关注的inclusive结构的高速缓存，在多核应用场景下，当共享的下级缓存写满之后，

有时会出现下层缓存因为不清楚上级缓存的使用情况，无效掉上层缓存常用数据的现象，而上层缓

存出于Inclusive维护的原因也会把该数据无效，这一系列操作导致上层缓存再使用该数据时需要

从更下级缓存或主存中重新读取，降低处理器效率，此现象被称为包容式缓存受害者。业界对于这

一问题有一些研究性的论文，其中一篇比较有代表性的IEEE论文分析了这一问题，并介绍了

TLH、ECI、QBI等三种优化方案[10]，这三种方案都能在一定程度上缓解inclusivecachevictim现

象，在本文第二章中会对三种方案进行详细的分析和比较。但是遗憾的是，除了学术论文外，业界

主流处理器设计公司对于这一问题的是否有成熟的解决方案并没有很多公开的信息，因此本文的优

化方案会基于AamerJalee论文中的三个方案为参照，对比优缺点。

东南大学工程硕士学位论文

1.3主要内容与设计指标

1.3.1论文主要研究内容

InclusiveCache结构的多核处理器中，当多核共享的下级缓存写满之后，有时会出现下层缓存

不清楚其上层缓存的使用情况，无效掉上层缓存常用数据的现象，而上层缓存出于Inclusive维护

的原因也会把该数据无效，导致上层缓存再使用该数据时需要花费大量开销从主存重新读取，严重

影响高速缓存的性能和效率。本文针对上述问题，提出一种把上层缓存的使用情况通过标志位目录

的方式对下级缓存数据维护提供依据，并以此优化下级缓存的替换顺序，避免上述错误无效上层缓

存常用数据的情况。并从而提高处理器执行效率和整体性能。本文基于作者一年来对Cache架构的

研究和模拟器测试的结果。

1.3.2设计指标

本文的主要功能指标为在GEM5模拟器中正常运行带有三级Cache结构的处理器模型，并在

Cache模型中加入带有upperAccess标志位的优化LRU替换策略，下级Cache能够通过upperAccess

标志位的状态判断上级Cache的使用情况。模型在修改后依然能够正常运转，并能够按照设计功能

做出更合理的替换选择，减少InclusiveVictim现象。

对于性能指标，参考AamerJaleel在IEEE上对不同缓存包含策略下命中能力的评判方法，以L2

和L3Cache的每千条指令的未命中数(MPKI)和每周期指令数(IPC)数据作为高速缓存与处理器整体

执行效率的判断依据，对比优化前后的缓存替换策略对缓存效率和系统整体性能的影响[10]。本文的

主要设计和性能指标如表1.2所示。

表1.2设计与性能指标

L1Cache

单核私有32KB+32KB

L2Cache

单核私有128KB

L3Cache

四核共享2MB

包含策略包含式(inclusive)

替换策略感应上级的LRU

MPKI优化目标降低3%

IPC优化目标提升1%

1.4论文组织框架

全文主要分为六章，结构安排如下：

第一章绪论

第一章介绍了高性能处理器高速缓存的研究背景和发展意义，对目前国内外主流缓存研究进行

介绍，以及本论文的主要内容和组织框架。

第二章介绍高性能处理器Cache-memory的结构，Cache一些关键技术的描述及其对处理器性

能的影响。比较各种缓存策略的优劣并分析InclusiveCacheVictim出现的原因。

第三章先简单介绍本文使用的GEM5模拟器平台，然后分析Cache部分的源码，解构GEM5

Cache架构的组成和运行的机制。

第四章用C++语言在模拟器平台中加入标志位目录改进缓存替换策略，介绍具体的实现方法。

第五章将加入感应上级LRU替换策略前后的模拟器模型使用SPECCPU2006测试，根据测试

结果分析修改前后的变化，以验证CacheVictim现象的改善效果。

东南大学工程硕士学位论文

第二章处理器高速缓存架构

在微处理器的体系结构中，Cache位于运算模块和主存(Memory)之间，以弥补Memory读写速

度与运算模块处理速度间的巨大差距。当处理器需要读取指令或者数据时，处理单元会优先从缓存

读取数据或指令，只有在缓存中没有所需内容的情况下再向主存查询和读取。这样做的原因是主存

的传输时延(Latency)是高速缓存的几十甚至上百倍，运算模块势必要浪费大量的时间在等待指令和

数据上，严重拖累了处理器性能。而在运算模块和Memory间加入速度更接近于运算模块的Cache

后，常用的数据和即将使用的指令能够更快的提供给运算模块，极大的提高了处理的效率[11]。因而

Cache架构和运行逻辑的设计对处理器的性能表现影响很大。

2.1高性能处理器的cache-memory结构

Cache-memory的基础结构如图2.1所示。

图2.1微处理器cache-memory结构

放眼当今世界上高性能处理器的cache-memory设计，主流处理器已经达成了一定的共识，即

L1采用数据和指令独立存储的哈佛结构，而L2和更低级的cache采用冯诺依曼结构。这样设计的

是出发点是L1cache与L2cache（以及L3或更多级的cache）的侧重点不同，是性能和效率上的一

种权衡。不同于主存使用的动态随机存取存储器(DynamicRandomAccessMemory,DRAM)，高速

缓存绝大多数是采用静态随机存取存储器(StaticRandom-AccessMemory,SRAM）实现的，SRAM

单元一般采用6个晶体管(6T)或8个晶体管(8T)组成一个bit的结构[12]，使其单元模块在整个芯片

的占用面积比例很高，尤其是近些年来高速缓存从两级逐渐增加到三级甚至四级之后，CPU裸片

(CPUDie)的面积越来越大，如图2.2所示，IBM最新的POWER9处理器中，仅L2和L3cache的

面积就占整个核心(Core)的近50%[13]，更大的cache面积必然导致更大的Die面积，从而大幅提高

东南大学工程硕士学位论文

处理器的生产成本。因此势必要将缓存的性能和大小折中到一个性价比相对较高的水平。独立的

L1指令缓存(InstructionCache)和数据缓存(DataCache)能够减少L1层级指令和数据读取之间的带宽

占用，让速度的优势达到极致；而L2及更下级Cache采用指令和数据共享结构以尽可能提高缓存

的利用效率，避免芯片的资源和面积浪费[14]。而相比于Cache，主存由于在片外不占用处理器面

积，基本上是随着时间变得越来越大[15]。

图2.2POWER9处理器Core结构

以两级缓存结构作为示例，主流高性能处理器的存储结构如图2.3所示。

计算单元

Load/Store单元

一级指令缓存一级数据缓存

二级缓存

系统总线接口

主存

图2.3微处理器缓存基本结构

处理单元需要读取指令或者数据时，处理单元会优先从指令/数据L1中查找数据或指令，如果

命中(Hit)就直接读取，如果L1未命中(Miss)，就继续到下一级的L2cache去查找，同样的，如果

L2命中便读取数据/指令供处理单元使用，一旦仍未命中就再依次向更低级Cache和主存查询和读

取。具体大致流程如图2.4。

第二章处理器高速缓存架构

从更下级cache/主

存读取

访存请求

访存类型

缓存命中?

写

读

返回数据

完成

写入下级cache/主

存读取

写入cache块

否

是

否

图2.4访存请求流程

当今高性能微处理器Cache的Latency根据Cache层级不同，相比于memory要低几倍到几十

倍不等，以AMD最新的Ryzen处理器为例，用AIDA64软件测试缓存和主存的Latency，如图2.5

所示。

图2.5AMDryzen处理器cache与memory的延迟

实测的数据显示，memory的时延是L1cache的70倍之多，即便是cache中最慢的L3

cache，其时延也只是主存的大约八分之一。由此可见，高效的使用cache的同时尽可能减少从主存

东南大学工程硕士学位论文

读写的次数，能够有效的提高处理器的整体性能。

无论是从L1、L2，还是主存读取数据或指令，都需要一定的访问时间。不可避免的，处理单元

在每一次等待数据时都会带来相应的开销，可以通过式（2.1）量化的算出平均访问时间。

失效开销失效率命中时间平均访问时间

（2.1）

式2.1中的命中时间（HitTime）为从定位缓存块、经标签比较并选中，一直到传回数据所需

的时间。失效率（MissRate）为在特定次数的内存访问中，发生缓存失效次数所占的比重。失效开

销（MissPenalty）是从定位缓存块、经标签比较判定失效，然后再从内存中定位数据并载入缓

存，最后直到把目标数据返回所需的时间[16]。从式2.1可看出，失效率和失效后对应的开销对访问

时间的拖累是同等量级的。更快的cache能够带来更低的失效开销，但其设计的复杂度和同容量下

显著增大的面积决定了容量必须限制，而相对更慢的cache和主存受累于访问时延较大，虽然容量

的优势很大，却也带来了更大的失效开销。因此，为了开销和性能的全局平衡，cache的容量必然

远小于memory，如何高效的利用cache显得极其重要[17]。

2.2高速缓存包含策略

处理器的高速缓存包含策略有多种不同的设计方式，根据其中一级高速缓存的内容是否存在于

其他级别高速缓存中来判断，一般分为包含式（Inclusive）、独占式（Exclusive）、非包含非独占式(NINE，

non-inclusivenon-exclusive)三种。

如果较高级别高速缓存中的数据块也必然存在于较低级别高速缓存中，则这两级高速缓存采用

inclusive策略。以两级inclusivecache结构为例，L2中完全包含L1中的内容。假设处理单元请求读

取某数据块(CacheBlock)，如果在L1cache中找到该数据块，则从L1读取数据并将其返回到处理器

的运算单元；如果在L1中找不到该数据块，但存在于L2cache中，则从L2中取出数据块并将其置

于L1中，如果这个过程导致一个块从L1中被驱逐(Evict)，不会影响到L2。如果在L1和L2中都找

不到该数据块，则只能从主存储器中取出该数据块并将其置于L1和L2中。这时如果L2中有数据

块被驱逐的情况，则L2cache会向L1cache发送反向失效，才能避免违反包含策略。

如果较低级别高速缓存仅包含较高级别高速缓存中不存在的数据块，则这两级高速缓存为

exclusive策略的高速缓存。同样以两级的exclusivecache结构为例。假设处理单元请求读取某数据

块，如果在L1cache中找到该数据块，则从L1读取数据并将其返回到运算单元。如果在L1中未找

到该块，但存在于L2cache中，则将该数据块从L2移动到L1，如果此过程导致某个数据块从L1中

被驱逐，则这个被驱逐的数据块被置于L2中，这也是L2填充的唯一方式。Exclusive下的L2其实

某处程度上就是L1的受害者缓存(VictimCache)。如果在L1和L2中都找不到该块，则从主存取出

第二章处理器高速缓存架构

该块并将其放置在L1而不是L2中。

NINE策略是介于inclusive策略和exclusive策略的的折中方式，如果较低级别缓存的数据块既

不是严格包含也不是严格独占于高级别缓存，则称其为NINE缓存。以两级的NINE结构为例。处

理单元请求读取某数据块，如果在L1cache中找到该数据块，则从L1读取数据并将其返回到运算

单元。如果在L1中未找到该块，但存在于L2cache中，则从L2中取出数据块并将其置于L1中，

如果这导致了某数据块从L1中被逐出，此过程不涉及L2，这与inclusive策略的情况一样。但如果

在L1和L2中都找不到该块，则从主存取出该块并将其置于L1和L2中。此时如果从L2中驱逐了

数据块，就与inclusive政策不同了，在NINE中L2并不用向L1发送反向失效[16]。

总体而言，Inclusive策略在CMP一致性维护上有着先天的优势，在每个核都有私有Cache的

并行系统中，如果发生CacheMiss，则先检查其他核同级的Cache。如果较内部缓存（InnerCache）

包含于较外围缓存(OuterCache)中，而OuterCache未命中的话，那么就无需在InnerCache中查找

了。与Exclusive和NINE策略相比，这意味着包容性缓存的延迟时间更短。Inclusive策略的最大缺

点是缓存的实际总容量就是OuterCache的大小，因为与ExclusiveCache中InnerCache和Outercache

的内容互斥的情况不同，Inclusive策略下的InnerCache内容必然都已经存在于OuterCache中。这

就意味着，Inclusive策略注定会更多的浪费缓存容量。相比之下，虽然Exclusive策略具有更多缓存

总容量的优势，但它维护过程会占用更多带宽，因为与仅填充新数据块的NINE策略相比，它具有

更高的数据块填充率，效果相当于InnerCache的MissRate更高。总而言之，三种缓存包含策略的

选择应同时兼顾性能和成本[16]。

2.3高速缓存的替换策略

高速缓存替换策略(或高速缓存替换算法)是计算机程序或硬件结构可以利用的优化指令或算法，

以便管理处理器上的高速缓存。通过一定的方法和规则将最近或经常使用的数据块保存在比正常存

储位置更容易访问到的位置，以来提高缓存性能。当缓存使用满时，算法必须选择需要丢弃的存储

块以便为新数据块腾出空间[18]。

前面2.1节中讨论了式2-1，知道了影响cache性能的两个主要参数：延迟和命中率。cache命中

率标志着了在cache中找到所需cacheline的频率。更高效的替换策略会跟踪更多使用信息以提高命

中率，而所有的替换策略都是命中率和延迟之间的折衷[19]。

当今主流处理器常用的缓存替换策略主要有LRU（最近最少使用,Leastrecentlyud）、PLRU

（Pudo-LRU）和RR(Randomreplacement,随机替换)，下面对这几种替换算法做简单的介绍。

LRU是首先丢弃最近最少使用的数据项。LRU算法需要保持跟踪何时使用哪个数据项，如果

东南大学工程硕士学位论文

想确保算法丢弃的数据项永远是最近最少使用的那个，其代价是昂贵的。LRU替换策略的实现基

于年龄位(AgeBit)的维护，并依赖于agebit跟踪最近最少使用的cacheline，每次使用cacheline

时，所有其他cacheline的年龄都会改变[20]。

Pudo-LRU(PLRU)是LRU的一种改良。对于具有大关联性(Associativity)的CPUcache（通

常>4路），LRU的实现成本变得过高。在许多CPU缓存中，丢弃最近最少使用的数个数据项之

一就完全足够，因此许多CPU设计人员选择PLRU算法，即每个缓存项只需要一位就可以工作。

PLRU通常具有稍差的missrate，但同时具有稍微较少的延迟开销，使用比LRU略低的代价带来比

LRU相比更低的开销[21][22]。

RR是随机选择候选项并在必要时丢弃它以腾出空间。该算法不需要保留有关访问历史的任何

信息。这种方法虽然看起来不可靠，但是根据实验测试，因为其几乎没有维护代价，在某些小型处

理器中有较为广泛的应用，比如ARM的Cortex-R系列处理器[23]。

由于GEM5模拟器平台默认是基于LRU替换策略的，本课题后面的优化主要是基于LRU替

换策略进行修改。

2.4inclusivevictim原因分析

目前生产工艺的发展稳步前进，但由于功耗与发热等方面的限制，处理器的频率已经在过去十

来年里并没有提高很多。所以在微架构的层面研究和提高，是当前提高处理器性能的关键渠道。出

于一致性的考虑，当前高性能处理器的高速缓存中Inclusivecache在L1cache-L2cache之间的应

用最为广泛。然而Inclusivecache有一个缺点：不同级别的cache只记录自身数据块的使用情况，

而不了解其他cache对数据块使用情况。举例来说，L1datacache与L2cache对于流水线的数据

的使用情况，了解程度会出现差异。L1Datacache对流水线使用数据块的情况最了解，而L2

cache则比较糟糕，导致L2cache会不清楚L1中数据的使用频率。仅依靠L2LRU的淘汰机制会把

L1datacache中正经常使用的数据块踢出，导致L1datacache发生本不该有的miss，增加了cache

缺失率。在多核应用中，一个共享的outercache对应多个innercache,outercache对每个核内的情

况了解有限，相对于单核情况，会更可能把innercache中的常用数据踢出，只能从更外围缓存或者

内存中重新读取数据，从而很大程度的影响处理器性能[6]。因此，本课题的目标是提出一种方法，

使outercache的替换策略更合理、有效地维护innercache常用的数据块，从而减少从更慢的存储中

读取数据的次数，提高处理器的性能[24]。

cachevictim发生原因示例如图2.6所示。

T=1和T=2时，L1/L2正常读取数据；

第二章处理器高速缓存架构

T=3时，L1&L2从LLC/主存读取d和e，L2中的a数据被LRU替换掉；

T=4时，L1再需要a时，虽然core0中有a，但core1和core0的L1并不共享，core1L1和L2

中都没有a，只能从LLC/主存中重新读取。

Ref

Core0L1

Core1L1

T=0

way0way1way2way3

T=1

Core0L1

Core1L1

T=2

cba

Core0L1

Core1L1

T=3

edcb

Core0L1

Core1L1

T=4

aedc

Core0L1

Core1L1

图2.6cachevictim发生原因

业界对于cachevictim的问题，提出过几种解决办法，简单介绍如下：

TLH（TemporalLocalityHints,局部暗示）消除inclusionvictim的办法是通过将上级cache的局

部性信息发送给下级，具体来说，是当上级cachehit时，将hit的信息通过TemporalLocalityHint

（TLH）发送给下级cache，该Hint不带任何数据，它被用来更新下级cache的替换状态。该方法

需要上级发很多信息给下级，即使使用了过滤器或者在L2与L3cache间使用，也还是有很大开

销，可实现性差，但可以作为其他优化方案的一个极限[10]。TLH法如图2.7所示。

东南大学工程硕士学位论文

图2.7TLH法示意图

ECI（EarlyCoreInvalidation，提前核缓存无效）的方法是在下级cache进行替换时，不仅要选

择出一个victim，还要通过向上级发送ECI信息，查询下次替换的victimcachelineA（次non-

MRU）是否在上级cache，如果上级cache有cachelineA，那么将其无效。等到上级Cache再次访

问cachelineA，那么该请求在上级cachemiss，而在下级cache命中，这样就可以更新下级cache

的信息了，如此一来下级cache也可以获得一定的局部性信息。该方案并未造成过多的通信开销，

但对时间要求很敏感，如果无效了上级后，在下级cache再次发生替换前，没有进行cachelineA的

再次访问，那么上下级cache都会miss[10]。ECI法如图2.8所示。

图2.8ECI法示意图

QBS（QueryBadSelection，查询选择）的方法也是在主要由下级cache发起的机制。与ECI

不同的是，QBS不是通过提前无效上级cache的次旧cacheline达到获取局部性信息的目的，而是

通过利用下级cachemiss的latency周期做掩盖，来向上级cache发起询问操作，询问上级cache是

否可以替换对应的victim，如果上级cache有该victimline，那么下级cache将其更新为MRU，然

后选择新的victim，并重复上面操作；如果上级cache没有该victimline，那么下级cache就可以将

其作为被替换的选项。当下级cache是LastLevelCache的时候，该机制发生的时机就是memory

access的时候，延迟较长，足以掩盖该操作的处理。如果memroy返回数据时，还没有选择出vic-

tim，那么需要等待，当然这里也可以控制victim查询迭代的次数来控制这种情况的发生[10]。QBS

法如图2.9所示。

第二章处理器高速缓存架构

图2.9QBS法示意图

本课题提出主要针对多核共享outercaches时感应上级的LRU替换策略，后文会在第四章详细

介绍。

2.5本章小结

本章首先介绍了高性能处理器cache-memory结构的组成及其工作流程。也介绍了对高速缓存

性能影响很大的cache包含策略和替换策略，并对几种方案的优劣进行简单的比较与分析。后面针

对本课题的主要议题，剖析inclusivecachevictim产生的原因，并介绍了业界已有的TLH/ECI/

QBS优化方案，比较和分析这些方法的优缺点并分析存在的局限性。总体而言，本章对业界主流

的高速处理器缓存架构进行了较为深入的分析，尤其是钳制inclusivecache性能的victim问题，确

定了提高下级cache对上级cache使用情况的了解程度为主要切入点，为第四章节提出本课题的解

决方案打下理论基础。

东南大学工程硕士学位论文

第三章GEM5模拟器的介绍与分析

处理器架构的性能评估主要方法主要有以下几种：

编写RTL代码并通过FPGA（现场可编程门阵列）实现，然后通过板级性能表现和硬件资

源的数据评判方案的效果。这种方法的主要问题是整个CPU架构是个庞大的工程，不可能

仅由单人或几个人完成；

通过在现有硬件上运行系统级性能分析工具Perf来测试处理器的详细性能。这种方法的问

题在于现在的方案只在想法阶段，并没有承载这种设计的硬件用于测试；

自主编写一个模拟器，然后通过运行SPEC_CPU2006或者在模拟器上运行操作系统运行

benchmark来评估微架构的优化效果。这种方案虽然理论可行，但是也需要较多人力和时间

才能完成，并不适合小规模的研究；

使用开源的模拟器平台，编写缓存及相关硬件的代码，其他处理器部件使用现有的开源模

块。这种方式可以有效降低测试平台的搭建工作量，虽然在性能上无法和完全自主编写的

整套模拟器相比，却是一套最可行的折中方案。

基于以上考虑，本课题选择在开源的GEM5模拟器平台上搭建测试平台。下文对GEM5模拟器

尤其是其cache模型进行介绍。

3.1GEM5的关键特性

GEM5模拟器由GEMS(GeneralExecution-drivenMultiprocessorSimulator，通用执行驱动的

多处理器模拟器)模拟器和M5模拟器结合而来，并由此得名。GEM5是一个可以用于研究计算机

系统级架构和处理器微体系结构的开源模拟平台。

GEM5模拟器的关键特性有：

多个可互换的CPU模型。GEM5提供了四个基于中断的CPU模型:一个简单的单cpi

CPU;顺序执行的详细CPU模型，以及乱序执行的详细CPU模型。GEM5还具有一个基

于KVM的CPU，使用虚拟化来加速模拟速度。

一个完全集成的GPU模型，它执行真正的机器ISA，并支持与主机CPU共享虚拟内存。

非MaliGPU模型。GEM5附带一个集成的NoMaliGPU模型，它与Linux和Android

GPU驱动程序栈兼容，因此不需要软件渲染。NoMaliGPU不产生任何输出，但确保以

cpu为中心的实验产生具有代表性的结果。

东南大学工程硕士学位论文

事件驱动的存储系统。GEM5拥有一个详细的、事件驱动的内存系统，包括缓存、

CrossBar、snoop过滤器，以及一个快速准确的DRAM控制器模型。GEM5的组件可以灵

活排列，例如，对复杂的多级非一致缓存进行建模。

同质和异质多核。CPU模型和缓存可以以任意拓扑组合，创建同构和异构的多核系统。

利用MOESI缓存一致性协议使缓存保持一致。

多种类ISA的支持。GEM5将ISA语义与其CPU模型解耦，支持对多个ISAs的有效支

持。目前GEM5支持Alpha、ARM、SPARC、MIPS、POWER、RISC-V和x86ISAs[25]

[26]。

3.2GEM5进行模拟仿真的基本机制

GEM5是基于事件驱动的模拟器，其基本机制主要由下面的4个类实现：

3.2.1ClassEvent

GEM5模拟器的每个操作都是事件(event)构成的，event类中包含了触发时间、优先级、下一event

的指针以及flag信息等。

Event对应的成员函数主要有以下几种：

在currentevent基础上插入或删除event：inrtBefore和removeItem

设置或获取信息：tWhen/when，tFlags/clearFlags/getFlags，scheduled,priority

操作符（基于when和priority）：大于、小于、不等于/等于

Event对应的处理：process，这是个纯虚函数，一定是有其子函数实现。

3.2.2ClassEventWrapper

EventWrapper对Event进行了很好的封装，它以template为模板，可以

创建默认的event并将模板类T的函数F作为该event的处理函数。

3.2.3ClassEventQueue

EventQueue是存储event的类，采用指向Event的指针链表实现。它的成员变量主要有一个头

指针head和一个当前时间_curTick.

EventQueue的主要成员函数有：

基本插入删除操作：inrt（需要调用Event：：inrtBefore）、remove（需调用Event：：

第三章GEM5模拟器的介绍与分析

removeItem）、异步插入asyncInrt

关于调度：

Schedule:将event插入queue中并标记为Scheduled

Deschedule：将event从eventQueue中删除并清除event的flag

Reschedule：如果已经schedule，那么删除并重新schedule；如果尚未schedule，那么

schedule。

关于Tick：获取当前时间：getCurTick；设置时间：tCurTick；获取下一时间：nextTick。

eventQueue的处理event：

rviceOne，从头获取一个event并调用该event的process函数。

rviceEvents：根据输入参数when，将所有小于该when时间的event都进行处理。最

终将CurTick设置为when。

3.2.4ClassEventManager

EventManager对EventQueue进行了封装，它的主要成员是EventQueue*eventq，主要函数是

EventQueue对应的各种调度函数。

因为基本都用eventManager进行封装了，因此在这里介绍下一个event的生命周期：

Schedule一个event加入eventQueue（整个系统有一个vectormainEventQueue，

各个线程的使用index1,2,3等，其他的用index0）。

当系统时间小于等于eventQueue中的最老时间，rviceOneevent，直到没有满足时间限制

的event

3.3多级cache的互联

GEM5支持多级cache的结构，本节以图3.1的4核的3级cache为例，介绍多级cache件的互

联的实现，理解多级cache的整体结构。

下图中的L1Cache（icache和dcache）和L2Cache是每个core私有的cache，而L3Cache是4

个核共享的Cache。由图的连接线可以看出，不同的cache，cpu和memory是通过port进行连接的：

每个cache都有唯一一个cpu_sideport，用来连接近cpu的port，接受请求并返回应答。同

时每个cache还都有唯一一个mem_sideport，来连接近memory的port。用来发送请求给

memory，接受memory返回的数据。

每个cpu都有一个dcache_port和一个icache_port，它们分别链接到对应的dcache：L1Cache

东南大学工程硕士学位论文

和icache：L1Cache的cpu_side的port上。通过此port的链接可以将cpu的请求发送给

dcache：L1Cache和icache：L1Cache。

L1Cache与L2Cache之间并不是直接连接的，而是通过tol2bus:CoherentBus中转了一下连

接起来的。这是为了更好的拓展，当多个上级cache都要连接到一个cache中的时候，例如

途中的L2cache与L3cache之间的关系，cache的port都是单一的，没有办法将多个cache

的mem_sideport直接连接到一个cache的cpu_sideport上。有了coherentBus就可以完成

这样的共享cache的连接了。

CoherentBus的slaveport就像cache的cpu_sideport一样，而masterport就像mem_sideport

一样，进行连接。

LLC（本例中是L3cache）的mem_sideport连接memoybus:MemBus的slaveport，并非

直接连接memory。同时连接到membus上的还有system_port,来处理不经过的cache的请

求。

图3.1GEM5三级缓存结构图

3.3.1不同存储部件信息的载体：ClassPacket

Cpu与L1cache之间，cache与cache之间，cache与memory之间，传送的信息的数据结构是

PacketPtr（即指向Packet的指针），要了解cache-memory子系统的处理流程，不可避免要理解Class

Packet（mem/）。

第三章GEM5模拟器的介绍与分析

3.3.1.1主要成员变量

Packet主要包含了请求类型及其属性，原始的request的指针、data信息、地址信息、byteValid

等，下面会分别介绍其中重要的数据结构。

Flagsflags：标记信息

Packet需要保存写标记，用于记录处理的信息，例如，当snoop有人响应了会置位MEM_INHIBIT。

MemCmdcmd：请求类型和请求的属性

MemCmd主要有以下两个信息命令类型Commandcmd和命令属性staticconstCommandInfo

commandInfo[]。

命令类型包含读、写、写回、预取、写无效等。

staticconstCommandInfocommandInfo[]：存储请求类型对应的属性，数据结构如下，其中attrib-

utes是一个位向量，不同位表示不同的属性，可以多位同时有效，表示多个属性同时具有，如果请求

需要respon，那么会有对应的reponcommand。

以ReadReq为例说明其CommandInfo的配置：{SET3(IsRead,IsRequest,NeedsRespon),

ReadResp,"ReadReq"}。Attributes是IsRead,IsRequest,NeedsRespon三个属性位同时有效，这很容

易理解，ReadReq是一个读操作（不是写），并且是一个请求（并非respon），并且这读请求是希望

获取数据作为回应的，因此NeedsRspon。对应的responcommand就是ReadResp，用于打印的字

符串就是"ReadReq"。

RequestPtr：CPU的原始请求

RequestPtr是一个指针类型，指向的时Request，为cpu的原始请求。主要包含更详细的信息，

包括architecture信息、是否为instruction请求、是否是uncacheable请求、虚拟地址、物理地址、

taskID、ASIDID、ThreadID等。

PacketDataPtr：data

typedefuint8_t*PacketDataPtr;

PacketDataPtr是个指向即uint8_t的指针类型，也就是说packet的数据是以8bit（即1Byte）为

一个单元存放的。

Addr：address

typedefuint64_tAddr

packet请求对应的地址，可能是虚拟地址，也可能是物理地址，有系统配置决定。

unsignedsize

请求的数据大小，以byte为单位。

东南大学工程硕士学位论文

MemCmdorigCmd

Command的原始命令，当且只有cmd有error的时候才会有效。

std::vectorbytesValid

保存read请求需要请求的是一个cacheline地址的哪些byte的信息。

3.3.1.2主要成员函数

构造函数

根据RequestPtr和MemCmd构造packet：Packet(constRequestPtr_req,MemCmd_cmd)和

Packet(constRequestPtr_req,MemCmd_cmd,int_blkSize)；需要cpu的原始请求，一般在cpu

的功能函数中调用。

根据packet构造函数：Packet(PacketPtrpkt,boolclear_flags,boolalloc_data)

Flags相关函数

Flags标志的t和get：tExpressSnoop()，isExpressSnoop()等。

请求属性相关函数

判断请求属性：isRead()，isWrite()，isRequest()等。

其他信息的相关函数

其他信息的设置tAddr(Addr_addr)，tData(constuint8_t*p)

获得responcommand：makeRespon

3.3.2连接不同部件的关键：Port类

Port类主要分为Master和slave两大类，并且遵循以下规则：

master和slave是成对出现的。

当port进行链接时，一定是master链接到slave，不可能master链接到master。

Master中会有一个_slavePort的成员来指示出对应slaveport，Slave中也会有一个_masterPort，

来指示对应的masterport。

Master(或Slave)port中的nd*函数其实是调用其对应的_slavePort（或_masterPort）的recv*

函数。

Master与Slave之间的发送或接受的请求的函数如图3.2。

第三章GEM5模拟器的介绍与分析

Slave-CPUSide

RespPacketQueue

Master-MemSide

ReqPacketQueue

SnoopRespPacketQueue

图3.2MasterPort与SlavePort之间函数

3.3.2.1CPU的port

CPU只有两个masterport，一个是用于访问data的DcachePort，一个是用于访问instruction的

IcachePort。两个port的继承关系如图3.3和图3.4。

图3.3DcachePort继承关系

东南大学工程硕士学位论文

图3.4IcachePort继承关系

3.3.2.2Cache的Port

每一个Cache都有两个Port，一个是CpuSidePort，一个是MemSidePort。两个port的继承关

系如图3.5和图3.6。

图3.5CpuSidePort继承关系

第三章GEM5模拟器的介绍与分析

图3.6MemSidePort继承关系

3.3.2.3CoherentBus的Port

CoherentBus的port有4个，slaveport有2个，masterport有2个。

父类中定义：std::vectorslavePorts;子类构造函数中调用的newCoher-

entXBarSlavePort。

父类中定义：std::vectormasterPorts;子类构造函数中调用的newCoher-

entXBarMasterPort。

std::vectorsnoopRespPorts;MasterPort，收到snooprespon的时候找到对

应的masterport，将respon转发。构造函数中newSnoopRespPort（slavePorts），也就是说

有一个slaveport就构造一个SnoopRespPort与之对应。代码中好像并没有实质用处。

std::vectorsnoopPorts;保存需要snoop的slaveport。是在init中赋值的，会遍历

所有slaveport，如果isSnoop，那么假如到snoopPorts中。Forwardingsnoop的时候会用到。

CoherentBusPort的继承关系如图3.7、图3.8、图3.9所示。

东南大学工程硕士学位论文

图3.7CoherentXBarSlavePort继承关系

图3.8SnoopRespPort继承关系

第三章GEM5模拟器的介绍与分析

图3.9CoherentXBarMasterPort继承关系

3.3.3ClassPacketQueue：关联Port和Event的关键

上一节中cache的port介绍中，cache的CpuSidePort或MemSidePort都是继承了QueueSlavePort

或QueueMasterPort。而Queue*Port中都包含了*PacketQueue，具体来说QueueSlavePort包含的

RespPacketQueue，QueuedMasterPort包含的ReqPacketQueue和SnoopRespPacketQueue，都是Pack-

etQueue的子类。这个PacketQueue就是将cache之间各种操作进行仿真推进的关键。

3.3.3.1主要成员变量

存储触发时间未到的请求的list

/**Alistofoutgoingpackets.*/

DeferredPacketListtransmitList;

EventManager，用来调度event

/**Themanagerwhichisudfortheeventqueue*/

EventManager&em;

Event的处理函数

/**Udtoschedulendingofdeferredpackets.*/

voidprocessSendEvent();

需要发送的时间。

/**EventudtocallprocessSendEvent.*/

东南大学工程硕士学位论文

EventWrapperndEvent;

是否由于retry在waiting状态

/**Rememberwhetherwe'reawaitingaretry.*/

boolwaitingOnRetry;

子类中增加了Port变量，这里是和cache相关处理的关键变量。

ReqPacketQueue：MasterPort&masterPort，该变量就是对应cache的对应port。子类ReqPack-

etQueue还有一个子类CacheReqPacketQueue。

SnoopRespPacketQueue：MasterPort&masterPort

RespPacketQueue：SlavePort&slavePort

3.3.3.2主要成员函数

deferredPacketReady：待处理transmitList中是否有到时间要处理的请求

processSendEvent:event的回调函数ndDeferredPacket

ndDeferredPacket：虚函数，可被子类覆盖。从transmitList选择最老的发送出去ndTim-

ing()，如果发送成功，schedSendEvent（条件成熟的情况下将下一个时间加入EventQueue）

即调度下一事件。这里要注意，Cache::CacheReqPacketQueue::ndDeferredPacket作为子类，覆

盖了积累的该函数，他可以直接从MSHR中获取packet并发送，成功后调度下一个事件。

ndTiming：纯虚函数，调用子类port的ndTiming函数；最终调用的时成对的port的recvTiming

函数，也就是cache中的各种recvTiming函数。

deferredPacketReadyTime：获取transmitList的最老请求的时间。

schedSendEvent：如果没有在等待retry并且输入参数when之前有事件可调度，那么调度一个事

件le(&ndEvent,when)。

schedSendTiming：将一个packet加入transmitlist，如果该事件的时间早于ransmitlist中最老的

事件，那么调度一个事件schedSendEvent(when)。

3.3.4连接不同部件的BUS：ClassCoherentXbar

GEM5通过ClassCoherentXbar连接不同部件的不同BUS，具体如下。

3.3.4.1成员变量

CoherentXbar的基类是BaXBar，因此成员变量包含的信息也体现在基类中，基类主要的变量

第三章GEM5模拟器的介绍与分析

如下：

固定的延时信息：

constCyclesfrontendLatency;

/**Cyclesofforwardlatency*/

constCyclesforwardLatency;

/**Cyclesofresponlatency*/

constCyclesresponLatency;

Bus的位宽

/**thewidthofthexbarinbytes*/

constuint32_twidth;

记录每个port的地址范围的map

AddrRanGEMapportMap

记录请求指针和port对应关系的map，m5::unordered_maprouteTo，如下情

况下要记录：

当收到上级的request时记录：收到下级的respon时查找，得到对应哪个上级的master，

获得连接该上级master的port。

收到下级的snoop时记录：收到上级的snooprespon时查找，得到当时snoop的下级slave，

获得连接该下级slave的port。

保存最近使用的3个port与addrRange的对应关系

PortCacheportCache[3]

保存slaveport的向量，slaveport要连接上面的多个master，一般slavePort会有多个，组成一

个向量：

std::vectorslavePorts;

保存masterport的向量，BUS的masterport一般只有一个。见运行后输出的文件。

std::vectormasterPorts;

ClassCoherentXbar的变量主要有：

针对request，respon和snooprespon，记录对应的master-slave转发packet的通道/layer是否

可用。该通道包含EventWrapperreleaEvent，通过事件及其事件

来完成对通道或layer的占用和释放。

std::vectorreqLayers;

std::vectorrespLayers;

东南大学工程硕士学位论文

std::vectorsnoopLayers;

std::vectorsnoopRespPorts;属于masterport，为每一个slaveport生成一个对应

的snoopresponport。

std::vectorsnoopPorts;记录snoopPort，在init时初始化，包括所有可以被snoop的

slaveport（连接的是上层的master），在处理snoop的时候进行snoop的转发

3.3.4.2成员函数

基类BaXBar的主要成员有：

PortIDfindPort(Addraddr)：根据地址找到对应的port

BaMasterPort&getMasterPort：获取masterport

BaSlavePort&getSlavePort：获取slaveport

ClassCoherentXbar的成员函数主要有：

boolrecvTimingReq(PacketPtrpkt,PortIDslave_port_id)：从上级发来，bus的slaveport收到一个

Timingrequest的处理。主要功能是转发其他上级master和通过bus的masterport发送给下级存

储。

boolrecvTimingResp(PacketPtrpkt,PortIDmaster_port_id)：从下级发来，masterport收到一个Tim-

ingrespon的处理。先通过routeTo找到连接对应上级master的slaveport，再将respon转发。

voidrecvTimingSnoopReq(PacketPtrpkt,PortIDmaster_port_id)：从下级发来，masterport收到一

个TimingSnoop的处理。先根据snoopfilter进行过滤，将snoop请求转发给上级master，然后

如果期望收到snoopRespon，那么在routeTo请求与该masterport的对应关系。

boolrecvTimingSnoopResp(PacketPtrpkt,PortIDslave_port_id)：从上级发来，slaveport收到一个

snooprespon，判断是其他上级的request产生的，还是下级snoop造成的。如果是其他上级，

那么通过对应的slaveport向上发一个TimingRespon出去；否则通过对应的masterport向下

转发这个SnoopRespon。

TickrecvAtomic(PacketPtrpkt,PortIDslave_port_id);与recvTimingReq类似，只不过没有时序，

无需recvTimingResp配合即可完成功能

TickrecvAtomicSnoop(PacketPtrpkt,PortIDmaster_port_id)：与recvTimingSnoop类似，只不过没

有时序，无需recvTimingSnoopResp配合即可完成功能

voidrecvFunctional(PacketPtrpkt,PortIDslave_port_id)：与recvTimingReq类似，只不过没有时

序，无需recvTimingResp配合即可完成功能。与atomic区别是，functional没有时序信息，不对

第三章GEM5模拟器的介绍与分析

packet记录delay信息。

voidrecvFunctionalSnoop(PacketPtrpkt,PortIDmaster_port_id)：与recvTimingSnoop类似，只不

过没有时序，无需recvTimingSnoopResp配合即可完成功能。

3.4单级cache结构图

GEM5的多级cache的实现是通过将同一Cache类（cache/中的BaCache类，对

应C++中的类为cache/中的Cache类）的例化成多个对象来实现的，理解了类的基本实现就

可以结合上一节介绍的多级cache的互联，对整个多级cache的实现有了清晰的认识。

cache

BaTags*tags()

mshrQueue

(cache/)

writeBuffer

(cache/)

CacheSlavePort*cpuSidePort(cache/)

CacheMasterPort*memSidePort(cache/)

BaPrefetcher

*prefetcher

()

图3.10Cache结构图

如图3.10所示，Cache类中包含了存储Cache的Data和Tag的存储阵列BaTags*tags，还包

含了用于存储和处理预取请求的BaPrefetcher*prefetcher，用于存储和处理cachemiss请求的

MSHRQueuemshrQueue，用于处理writeback请求的MSHRQueuewriteBuffer。除了以上存储部件，

还包含了近CPU端的CacheSlavePort*cpuSidePort，近memory端的CacheMasterPort*memSidePort，

以及两个port对应的receive/ndevent的处理函数recvTimingReq，recvTimingSnoopReq等，nd

东南大学工程硕士学位论文

event最终调用的也是对应上下级cache的recv*函数，因此只要分析recv端的处理即可[27][28]。

3.4.1组相联cache：ClassLRU

组相联cache的代码在src/mem/cache/tags/。如果直接看BaCache类的代码实现，很容易被误

导，以为src/mem/cache/tags/为组相联cache的代码实现。其实通过python类与C++类对应

的时候，已经将LRU类设置为tags的默认类了，因此LRU为组相联cache实现的类，该ClassLRU

继承了ClassBaSetAssoc，而ClassBaSetAssoc又继承了ClassBaTags。而主要的数据结构大部

分都在ClassBaSetAssoc中实现了。

Cache的特征信息有：

constunsignedassoc;几路组相联

constunsignednumSets;多少组

Cache的存储数据的部分包括：

最基本的cacheblock数据结构：ClassCacheBlk

该类中包含了asid，tag，t信息，data的指针等。

SetType*ts;

typedefCacheSetSetType;

CacheSet类存储了assoc和CacheBlk的指针的指针。

BlkType*blks;

typedefCacheBlkBlkType;

blks存储了指向所有的cacheblock的指针

uint8_t*dataBlks;

存储了所有cacheblock对应的数据

以上cache特征和存储部分的初始化代码如下，代码中可以看出ts保存的时指向BlkType的

指针数组；blk是真正的BlkType内容组成的数组；dataBlks保存的是cache对应的数据。

ts=newSetType[numSets];

blks=newBlkType[numSets*assoc];

//allocatedatastorageinonebigchunk

numBlocks=numSets*assoc;

dataBlks=newuint8_t[numBlocks*blkSize];

unsignedblkIndex=0;//indexintoblksarray

for(unsignedi=0;i

第三章GEM5模拟器的介绍与分析

ts[i].assoc=assoc;

ts[i].blks=newBlkType*[assoc];

//linkinthedatablocks

for(unsignedj=0;j

//locatenextcacheblock

BlkType*blk=&blks[blkIndex];

blk->data=&dataBlks[blkSize*blkIndex];

++blkIndex;

//invalidatenewcacheblock

blk->invalidate();

//EGHFixMe:doweneedtoinitializeblk?

//Settingthetagtojisjusttopreventlongchainsinthehash

//table;won'tmatterbecautheblockisinvalid

blk->tag=j;

blk->whenReady=0;

blk->isTouched=fal;

blk->size=blkSize;

ts[i].blks[j]=blk;

blk->t=i;

}

Cache的常用操作有：

Cache的常用操作主要由函数完成，包括：

CacheBlk*accessBlock(Addraddr,boolis_cure,Cycles&lat,int

context_src);根据地址查找cache，返回找到的cacheblock。

voidinrtBlock(PacketPtrpkt,BlkType*blk);将packet的数据及信息赋值给blk，并将该blk

放到该t队头（避免作为victim）。

voidinvalidate(CacheBlk*blk);将blk的标志位置为无效，并放到该t队尾（优先替换）。

Cache的替换算法相关内容：

CacheBlk*findVictim(Addraddr);将对应t队尾block返回，作为victim。

东南大学工程硕士学位论文

3.4.2MSHRQueueMissQueue/writebuffer

3.4.2.1ClassMSHRQueue

MSHRQueue是保存Miss请求或者write请求的Queue。顾名思义，它是若干要发往bus的请求

组成的Queue的结构。主要包含的信息如下：

MSHRQueue的特征信息

constintnumEntries：Queue的深度

intallocated：已经分配的项数

intinServiceEntries：已经发送请求到bus的项数

constintindex：在该cache中的index，用于区分是MissQueue还是WriteBuffer。

MSHRQueue维护信息

MSHR::ListallocatedList：已经分配的MSHRentry列表。

MSHR::ListreadyList：指示还未发往bus并且已经ready的请求。

MSHR::ListfreeList：尚未分配的MSHRentry列表。

MSHRQueue核心存储结构

std::vectorregisters：保存了所有MSHRentry

MSHRQueue主要功能函数

MSHR*findMatch(Addrblk_addr,boolis_cure)：在allocatedList中查找是否有MSHR与给

定的addr和cure属性相同的entry，如果有，则返回。

boolfindMatches(Addrblk_addr,boolis_cure,std::vec-

tor&matches)：在allocatedList中查找是否有MSHR与给定的addr和cure属

性相同的entry，直到遍历完allocatedList，返回所有符合的MSHR指针的vector。

MSHR*findPending(Addrblk_addr,boolis_cure)：从readylist中找到地址和属性相同的

MSHR返回，用于判断MissQueue与writeBuffer的冲突。

MSHR*allocate(Addrblk_addr,unsignedblk_size,PacketPtrpkt,Tick

when_ready,Counterorder)：在freelist中分配一项MSHR给制定的packet

voiddeallocate(MSHR*mshr)：删除一项MSHR

voidmarkInService(MSHR*mshr,boolpending_dirty_resp)：标记MSHR已经发往BUS。

voidmarkPending(MSHR*mshr)：标记一个MSHRentryready，重新发送MSHR的deferredtar-

gets的请求。

第三章GEM5模拟器的介绍与分析

MSHR*getNextMSHR()：获得readylist的表头MSHR。

3.4.2.2ClassMSHR

作为MSHRQueue的每个entry，MSHR的数据结构和主要功能函数如下：

TickreadyTime：ready的时间

bool_isUncacheable：是否是uncacheable请求

booldownstreamPending：下级cache是否pending（由于该请求指针会传递到下级cache，

因此下级cache可以设置此信息）

boolpendingDirty：完成请求后是否获得Dirtydata

boolpostInvalidate：等待数据返回的时候监听到了Invalidate的snoop请求。

boolpostDowngrade：等待数据返回的时候监听到了read请求。

MSHRQueue*queue：该entry所在的queue

AddrblkAddr：该MSHR中保存请求的地址

boolinService：该请求是否已经发往了BUS。

boolisForward：该请求是否为上级cache发起，本级cache只做转发

TargetListtargets：用来保存MSHR请求返回后需要服务的原始请求。比如，来自上级cache

的请求，或来自prefetch的请求，或来自snoop的请求。相同地址的请求，都会加入到一个

MSHR的TargetList中。

TargetListdeferredTargets：由于某些原因，需要延迟处理某些请求，导致无法将原始请求放

入TargetList中，需要放入deferredTargets中。例如该MSHR已经发了请求到BUS，并且

前面有请求在等待数据返回后进行invalidate操作。

voidallocate(Addrblk_addr,unsignedblk_size,PacketPtrpkt,Tick

when_ready,Counter_order)：分配请求到该MSHR

voiddeallocate()：将该MSHR放入freelist。

voidallocateTarget(PacketPtrtarget,Tickwhen,Counterorder)：收到TimingReq的时候将请求

加入MSHR的targets或deferredTargets中。

boolhandleSnoop(PacketPtrtarget,Counterorder)：收到snoop的处理：

snoop请求如果需要exclusive数据，查看targets是否需要将请求类型更新。例如

UpgradeReq更新成ReadExReq，SCUpgradeReq更新成SCUpgradeFailReq，StoreCon-

dReq更新成StoreCondFailReq。

东南大学工程硕士学位论文

如果前面已经有在等待的invalidatesnoop，如果有，最终cache状态是invalid，那么无

需任何操作，直接返回true。

如果本MSHR在等待Dirty数据或snoop需要invalidate，那么数据到来后再返回snoop

respon，将此snoop生成新的packet加入targets中，等待处理。其中如果MSHR在

等待Dirty数据，那么设置snooppacket已有cache响应并提供exclusive数据，返回

true。

如果snoop不需要exclusive数据，并且是cacheable请求，那么标记MSHR的

postDowngrade，并进行snooppacket的asrtShared操作，返回true。

voidMSHR::handleFill(PacketPtrpkt,CacheBlk*blk)：收到TimingRespon后要进行Fill操

作的处理：如果targets并不要求获取exclusivedata，但是返回了exclusivedata，此时可以

更新deferredTargets，将其合并入targets。

3.4.3主要Port对应的ReceiveEvent的处理

3.4.3.1recvTimingReq函数

该函数是cache处理来自上级cache的请求的，主要处理如下：

如果已有其他cache处理，要看是否有遗留工作，如继续invalidate系统其他cache的副本

如果没有其他cache处理，查找本cache，如果本cache可以满足请求的需要，那么发送

respon；否则就是cachemiss

Cachemiss需要查找MSHR，如果命中，只要在对应MSHR增加targets即可；否则需要根

据请求类型，看是分配writeBuffer还是MissBuffer。

另外，根据配置和需要。更新prefetcher，处理prefetch的请求。

recvTimingReq流程图如图3.11。

第三章GEM5模拟器的介绍与分析

CacheDisable？

memSidePort发送

ndTimingReq

如果是L1，将整

cacheline的WriteReq

升级为

WriteInvalidateReq

该请求已有cache

响应？

请求需要E,但是响

应者只能提供O？

生成snoop；

设置已有cache响应；

通过memSidePort发

送ndTimingReq

Returntrue

访问本级cache；

如果有writeback产

生，分配

WriteBuffer；

本cache满足请

求？

更新prefetcher；

如需respon，通过

cpuSidePort发送

schedTimingResp

在match的MSHR中增

加一个target；

如需要，通知

prefetcher

在mshrQueue查

找到MSHR项？

如果么有找到

MSHR，生成一个

prefetch请求；

将原请求转为

respon

cpuSidePort发送

schedTimingResp

原请求更新为

prefetch请求

L1&SwPrefetch？

Writeback或

uncacheable

write？

分配writeBuffer

如果cache找到的

block有效，先将其置

为不可读状态；

分配MissBuffer

如需要通知prefetcher

memSidePort发送请

求；

prefetcher的时间

小于最大值？

Returntrue

开始

图3.11recvTimingReq流程图

3.4.3.2recvTimingResp函数

该函数是cache处理来自上级cache的请求的，主要处理如下：

确定MSHR以及是否需要进行fill，需要的话进行MSHR的fill和cacheblock的fill

处理所有可以处理的MSHR的target：根据来源不同进行不同处理：来自CPU的，进行fill

操作，更新原请求信息，计算延时信息，发送respon给上级；来自prefetcher的，更新

block信息，删除该target；来自snoop的，完成未完成的snoop处理，参recvTimingSnoopReq

东南大学工程硕士学位论文

MSHR如果还有延迟的target，那么更新MSHR的readylist，发起memSidePort请求

处理writebacks，如果有新的writeback产生，在writebuffer中为其分配一项entry，并且发

起memSidePort请求。

recvTimingResp流程图如图3.12。

MSHR没有target

清除由于MSHR没有

target造成的block；

获得MSHR对应的

target；

查询本cache，找到对

应的cacheblock；

计算misslatency；

根据收到的respon

packet得到对应的

MSHR

Fill&没有Error?

MSHR处理fill：有必

要的话，更新Targets

Cacheblock处理fill：

替换和标志位设置

Mshr有target？

Target

source=CPU？

NTarget

source=prefetcher

Target

source=snoop？

处理snoop（与收到

snoop处理大致相

同）

更新block为

HWPrefetched；

删除targetpacket；

如果是L1&SWprefetch，

那么删除target；

如果是L1&写无效操作，

那么MSHR处理fill，

Cacheblock处理fill，fill有

效；

错误

MSHRpopTarget

需要Fill？

satisfyCpuSideRequest：根

据target请求类型不同，设

置原请求不同的标志位；

计算misslatency

Cmd=

UpgradeFailResp

计算完成时间；

更新返回数据；

如果是读操作：用

respon的packet对Target

packet进行Setdata

将targetpacket变为

respon；

更新delay信息；

cpuSidePort发送

TimingResp；

Cacheblock有效的

话。根据需要进行无

效或置为不可写；

MSHR是否有

deferred的target

Cacheblock置为不可

读；

更新MSHR的

readylist；

请求MemSide发送

request

删除MSHR；

如果必要，清除由于

MissQueue满造成的

阻塞；

计算prefetcher的时

间，若需要，请求

MemSide发送request

Writebacks不空

为writeback分配

WriteBuffer；

Writebackpop；

如果cacheblock用的

临时的：如果dirty，

为其分配

WriteBuffer；否则无

效掉。

删除respon

packet；

结束

开始

图3.12recvTimingResp流程图

第三章GEM5模拟器的介绍与分析

3.4.3.3recvTimingSnoopReq函数

该函数是cache处理来自下级cache的snoop请求的，主要处理如下：

查找cache，如果命中，返回一个block，为了后续更新状态或为snoop提供数据或被无效

查找mshrQueue，如果命中，由MSHR处理snoop。

查找writebuffer，根据snoop的需要，设置snoop结果或数据或无效对应的writeback。

recvTimingSnoopReq流程图如图3.13。

Writeback或不是

有效地址范围？

查找cache；

查找mshrQueue;

开始

命中mshr且

snoop是

HardPFReq？

不接收从下级cache来

的prefetch请求，

tBlockCached

命中MSHR且

MSHR可以处理

snoop？

等待MSHR处理即可

查找WriteBuffer

命中

设置snoop请求的结

果，状态和数据

如果snoop要求

invalidate，那么清除

该writeback

HandleSnoop

图3.13recvTimingSnoopReq流程图

HandleSnoop的处理流程如下，主要包括步骤有：

转发给上级，收集上级结果并设置snoop的packet

驳回prefetch的snoop

如果是readsnoop，更新cacheblock的标志位

东南大学工程硕士学位论文

如果需要Respon且本级cache可以提供respon，设置snooppacket的结果和数据，发送

snoopRespon

如果是invalidatesnoop，无效cacheblock。

HandleSnoop的处理流程如图3.14所示。

3.4.3.4recvTimingSnoopResp函数

该函数是cache用来处理来自上级cache发回的SnoopRespon的。主要处理包括：

如果respon是HardwarePrefetch命令的，那么当做接收到TimingRespon一样处理

计算snooprespon的时间，将SnoopRespon转发到下级cache。

第三章GEM5模拟器的介绍与分析

HandleSnoop开始

转发给上级？

生成snooppaket；

发送给上级；

根据上级的反馈设置该

snooppacket

Block无效？

不接收从下级cache来的

prefetch请求；

Snoop是HardPFReq？

Snoop如果是读请求，更新

block的权限和snoop的结果

Snoop需要respon&不

invalidate&block是

Dirty

设置snoop的结果和数据；

发送snooprespon

Snoopinvalidate？

无效Cacheblock

图3.14HandleSnoop处理流程

东南大学工程硕士学位论文

3.5本章小结

本章主要为了测试实验的需要，以GEM5现有的cache模型出发，理清了本文采用的实验平台

GEM5模拟器的主要机制，包括GEM5的事件驱动机制；多级cache的互联结构及其中主要组件的

实现；GEM5的cache中存储模块和MissQueue即对于接收到Event的处理实现。本文的优化方案

的实现是建立在上述分析的基础之上的，有了对GEM5平台及其机制的深入分析，才能在其基础

上实现本文的优化方案。下一章就将在本章的基础上，详细阐述如何提高缓存的性能。

第四章缓存替换策略的优化

基于第二章对于inclusivecachevictim问题的剖析和第三章对GEM5模拟器cache模型代码的分

析，本章将对cache模型进行修改，以模型自带的LRU为基础，加入感应上级的LRU替换策略，

并对功能实现的具体方法进行阐述。

4.1缓存性能的优化方案

鉴于2.3节的inclusivevictimcache背景，如果想解决victimcache，一种直观的方案就是将上级

Cache的局部性信息发送给下级cache，下级cache在替换的时候，结合上级cache和本级cache综合

的局部性信息进行替换，从而避免替换上级cache的内容。因此，本文特此提出了一种优化方案：

为下级cache的每一个cacheline或cacheblock维护一组标志位upperAccess，用来指示上

级cache中是否包含该cacheline以及上级cache的哪个cache包含该cacheline。

当由于上级miss且下级miss进行回填Fill操作时，那么在下级cacheline标记对应的上级

cacheline包含该cacheline。

当上级cache进行替换时，不论被替换的cacheline是否为Dirty数据，都将该替换信息传递

到下级cache，用于更新下级cache的标志位upperAccess。

下级cache的替换策略如下：优先选择无效的cacheline；如果没有，优先选择不在上级cache

中的cacheline，即upperAccess无效的cacheline；如果都有效，那么优先选择较少上级cache

的upperAccess有效的cacheline。如果被替换的cachelineupperAccess有效，鉴于inclusive

机制，将发起对上级cache的无效操作，由于下级cache可以精确的指示出哪个上级cache，

就避免了不必要的无效操作。

本方案与之前方案的主要区别或优势在于：

本方案的实现代价低：本方案只需要在cacheline的tag中增加几位upperAccess的信息，无

效增加上级cache的目录或map来实现获取上级cache的使用信息。

本方案实现可行性高：相比理想化的TLH方案，本方案增加的上级发送给下级的信息是基

于每次上级cache未命中且被替换的cacheline为Clean的时候，而TLH是上级cache将所

有命中信息发送给下级cache，由于未命中率远远小于命中率，尤其是靠近CPU的cache，

因此相比于不可实现的TLH方案，本方案具有很强的可实现性。

本方案可以尽可能的减少不必要的snoop请求：相比于QSB方案，本方案可以做到精确的

东南大学工程硕士学位论文

定位是上级那个cache发生了替换而不需要将snoop请求广播给所有上级cache，而QSB中

就必须将所有请求向上广播。

本方案也有一些缺陷，当上级cache太多，比如核数增多，如果想在共享cache实现该机制，那

么共享的cache的upperAccess标志位会线性增长，可能是该方案代价变高。当然这种情况可以采用

多个上级cache公用一个upperAccess来实现。

4.2缓存性能优化的实现

本文的缓存优化方案均基于比较稳定的GEM5版本GEM5-stable_2015_09_03实现。

4.2.1下级cache增加信息记录上级cache的使用情况

下级cache的每个cacheline都要增加一组标志位信息，用来表示对应的上级cache是否包含该

cacheline，结构如图4.1所示。采用map结构，在mem/cache/的ClassCacheBlk中增加如下成

员变量：

mapupperAccess

其中，该upperAccess的size为包含该cacheline的上级cache的个数;对于upperAcess[MasterID]>0

表示上级有该cacheline，否则表示上级没有该cacheline。目前该upperAccess只有可能是0和1两

个值。之所以使用int类型，而不是bool类型，是为了以后扩展到更多的方案使用，例如大于1表

示上级有该cacheline；等于1表示上级最近包含该cacheline，但目前没有；等于0表示上级目前并

且最近都没有该cacheline。这样可以做更多的实验。

DataVTagDUCacheline1

Cacheline2

CachelineN

DataVTagDU

Valid

Dirty

UpperAccess

其他标志位

图4.1下级cache记录信息的结构

该upperAccess的标志位的维护如下：

在整个cache初始化的时候，该map结构为空。

第四章缓存替换策略的优化

当上级cache和下级cachemiss造成回填Fill的时候，此时下级cache进行操作upperAc-

e(upperMPortID,1)。具体体现在Cache::recvTimingResp的处理中，当对应的Miss

请求的原请求来自CPU，那么若本级cache不是L1cache，且需要进行Fill操作，必然也

要回填进入上级cache的，那么就可以进行e的操作了，只不过这里值

得注意的是，除了要求本级cache不是L1Cache，还要求原始请求不是指令cache或TLB

miss造成的，因为这两种请求再L1都是只读的，inclusive机制只要保证L1datacache就可

以，另外TLB或指令在上级中存在不代表在本级cache中是优先不替换的cacheline。

当上级cache替换掉一个cacheline的时候，发送writeback或evict请求给下级cache，此时

下级cache进行操作：(upperMPortID)。

当一个cacheline进行无效操作的时候，将对应的upperAccess清除。

4.2.2上级cache增加替换Cleandata告知下级cache的机制

如上节所述，upperAccess的清除操作依赖上级Cache将其替换信息发送给下级cache。其中，

上级cache如果被替换的cacheline是Dirty的，那么原本的机制就会保证上级cache会发送该信息给

下级cache；如果被替换的cacheline是Clean的，那么默认上级cache是不会将此信息告诉下级cache

的，因此要增加一个命令evictWithoutData，该命令的产生、传递和处理与writeback命令都是类似

的，只不过不带有Dirty的cacheline数据。上级cache增加替换Cleandata告知下级cache的机制流

程如图4.2所示。

Tol3bus

L2L2L2

被替换的cacheline产生

evictWithoutData

发送给tol3bus

转发给L3

收到evictWithoutData,将对应

cacheline的相应的L2的upperAccess清除

图4.2evictWithoutData机制

东南大学工程硕士学位论文

4.2.2.1增加新的命令evictWithoutData

这部分的改动主要在ClassMemCmd，参见3.3的介绍。在枚举类型Command中，增加evictWith-

outData命令。

还需要在枚举类型Attribute中增加IsEvict的属性，用来判断该命令是否为没有Dirty数据的

cache替换造成的，该函数的实现如下：

boolisEvict()const{returntestCmdAttrib(IsEvict);}

其他的命令属性主要在CommandInfo中包含，设置如下：

conststd::bittattributes：是evict所以要设置IsEvict,

是一个请求所以要设置IsRequest。

constCommandrespon：因为不需要对应的respon，该请求发给下级cache后交由下级

cache处理即可，因此没有repon，该信息是无关项。

conststd::stringstr：表示该命令的字符串为"evictWithoutData"

4.2.2.2evictWithoutData的产生

该命令的产生主要参照writeback的产生，区别在于writeback针对的是所有cache被替换的cacheline

是Dirty的情况，而evictWithoutData针对的是非LastLevelCache（LLC）被替换的cacheline是Clean的

情况，之所以要排除LLC是因为LLC的下级memory无需维护upperAccess信息。因此需要为cache增

加为LLC的信息，该信息需要从python类到C++中的mem/cache/都都要增加：constboolis-

LastLevel。

与writeback的生成函数PacketPtrCache::writebackBlk(CacheBlk*blk)类似，本方案的实现也编写了

对应的PacketPtrCache::evictBlk(CacheBlk*blk)函数代码，主要区别有以下：

asrt(blk&&blk->isValid()&&!blk->isDirty())：断言被替换的blk是Clean的，即isDirty无效。

PacketPtrwriteback=newPacket(writebackReq,MemCmd::evictWithoutData)：这里命令类型从

Writeback变为evictWithoutData

调用evictBlk，即生成evictWithoutData的情景包括：

在收到上级Cache或CPU的命令（在Cache::recvTimingReq函数中），进行cache查询（在

Cache::access函数中）：如果请求是uncachable，却又命中cache，这时候需要进行无效操作，如

果无效的cacheline是Clean的并且当前cache不是LastLevelcache，那么需要调用evictBlk。

在收到上级Cache或CPU的命令（在Cache::recvTimingReq函数中），进行cache查询（在

Cache::access函数中），如果请求是writeback，并且本级cachemiss，那么需要分配新的block保

第四章缓存替换策略的优化

存该writeback的数据（在Cache::allocateBlock中），分配block就需要进行替换，找到一个victim

cacheline，如果该victimcacheline是有效且Clean的，并且当前cache不是LastLevelcache，那

么需要调用evictBlk。如果是个普通的read请求且本级cachemiss，难道不用替换吗？这种情况

的实现其实需要等到miss的cacheline返回数据进行回填的时候才进行，即下面的情况。

在收到respon时（在Cache::recvTimingResp函数中）时，需要Fill时（调用Cache::handleFill），

会选择一个victimcacheline替换掉，同样的，如果该victimcacheline是有效且Clean的，并且

当前cache不是LastLevelcache，那么需要调用evictBlk。

4.2.2.3evictWithoutData的传递

evictWithoutData的传递是由CoherentXbar完成的，该部分较简单，但是有一点需要注意：由于

下级cache对应的上级cache有几个，都有哪几个，这个信息只在CoherentXbar中可以得到，因此

CoherentXbar就需要完成这部分信息的传递。

CoherentXbar会以snoop的方式将请求向上传递给其他上级cache，而evictWithoutData无需进

行该操作，需要在CoherentXbar的recvAtomic和recvTimingReq中屏蔽掉。

在Packet中增加上级cache的ID信息（mem/）：std::vectorupperMPortID。

该信息之所以是vector类型，而不是普通的uint32_t的原因是：两级cache或cache与memory之前

传递请求或相应等是通过指向Packet的指针，并且当两级cache都miss的时候，例如L1cache和L2

miss都miss了，同一请求指针会经过两级CoherentXbar，如果是普通的uint32_t类型，那么第二次

经过CoherentXbar的时候，L2记录的是哪个L1miss的信息就会被L3需要记录L2是哪个的信息覆

盖掉，造成数据丢失和错误。因此需要将其改为vector类型。在进入CoherentXbar的时候push最新

的上级cache的ID，在结束上级请求在本级cache的处理（例如收到respon进行完Fill后）之前，

进行上级cacheID的pop，保证上一级Cache收到的时候对应的是它的上级cacheID。

pkt->_back的情况包括：

CoherentXBar在收到请求的处理中（recvTimingReq函数），获取了连接上级cache的

slave_port_id后，增加pkt->_back(slave_port_id)

CoherentXBar在收到请求的处理中（recvAtomic函数），获取了连接上级cache的

slave_port_id后，增加pkt->_back(slave_port_id)

pkt->_back的情况包括：

Memory收到请求进行access时，由于memory一定可以完成该请求，可以在该处理前期就

将upperMPortID执行pop操作，为了保险起见，一定要在执行pop前确认upperMPortID的

东南大学工程硕士学位论文

大小大于0。该处理在AbstractMemory::functionalAccess和AbstractMemory::access均需要

实现。

在收到上级Cache或CPU的命令（在Cache::recvTimingReq函数中），进行cache查询（在

Cache::access函数中），如果请求是writeback，并且命中（当然在inclusive的情况下，肯定是会

命中的），那么该请求可以在本级完成，将上级cacheIDpop出即可。

在收到上级Cache或CPU的命令（在Cache::recvTimingReq函数中），进行cache查询（在

Cache::access函数中），如果请求是evictWithoutData；不论该地址是否命中本级cache（当然在

inclusive的情况下，肯定是会命中的），该请求都不会向下传递了，该请求可以在本级完成，那

么将上级cacheIDpop即可。

在收到respon时，逐个处理MSHR的targetpacket的时候，如果原请求来自CPU端，那

么返回respon前将上级cacheIDpop。

收到上级的recvAtomic时，由于该请求一定可以在本函数内处理完毕（本函数内部如果需

要发往下一级cache也会在本函数内部处理完），因此在返回前增加上级cacheIDpop的处

理即可。

4.2.2.3evictWithoutData的处理

evictWithoutData的处理其实较为简单，在下级cache可以直接完成，不存在多级cache的多层

传递问题。而evictWithoutData命令的处理主要在recvTimingReq/recvAtomic的access中，为此而增

加的处理如下：

获取上级cacheID信息

将pkt的upperMPortID进行pop操作

如果本级cache命中，那么清除对应cacheblock的upperAccess中对应的上级cacheID的

标识

返回true。

4.2.3支持多级cache间的包含机制

由于本方案是基于inclusive的cache进行的，而本方案的GEM5平台版本默认仅支持non-

inclusive且non-exclusive的机制，因此需要针对本版本代码，增加对inclusive包含机制的实现。

Inclusive机制较于non-inclusive且non-exclusive的区别只在于，cache进行替换的时候，需要snoop

上级cache，将被替换的cacheline内容从上级cache中也剔除，以保证下级cache没有的cacheline上

第四章缓存替换策略的优化

级cache也必然不存在。具体实现就是只要增加一个机制：非toplevel的cache要清除掉victimline

时，向上发送对应地址的无效请求。

为了兼容原来的non-inclusive且non-exclusive策略，本方案需为cache增加一个inclusive的控

制信息constboolInclusive。

向上级cache发送无效请求的实现，本文采用自下而上发起的snoopReq实现，使用cache的

recvTimingSnoopReq，采用的命令是InvalidationReq，该命令无需返回SnoopRespon。

生成该InvalidationReq请求的情况就是所有进行替换要产生writeback或evictWithoutData的时

候，因此只要在Cache::evictBlk和Cache::writebackBlk中增加如下代码：

if(Inclusive&&!isTopLevel&&blk->()>0)

{

UpperInv(writeback);

}

上述代码中Cache::UpperInv(PacketPtrpkt)的处理如下：

根据pkt生成一个新的snooppacket

将snooppacket的命令修改为InvalidationReq

初始化Delay=dDelay=0

cpuSidePort执行ndTimingSnoopReq(&snoopPkt)

Inclusive的维护方式如图4.3所示。

L2收到Invalidsnoop

进行无效操作

转发invalidsnoop

请求给指定的L2

LRU替换cacheline，如果对应的upperAccess

有效，产生invalidsnoop请求

Tol3bus

L2L2L2

发送invalidsnoop请求到tol3bus

图4.3Inclusive的维护流程

具体源码如下：

voidCache::UpperInv(PacketPtrpkt)

{

//copythepacketsothatwecanclearanyflagsbefore

东南大学工程硕士学位论文

//forwardingitupwards,wealsoallocatedata(passing

//thepointeralongincaofstaticdata),inca

//thereisasnoophitinupperlevels

PacketsnoopPkt(pkt,true,fal);

=MemCmd::InvalidationReq;

ressSnoop();

Delay=dDelay=0;

cpuSidePort->ndTimingSnoopReq(&snoopPkt);

}

4.2.4替换算法的修改实现

替换算法原本采用的是LRU策略，本文在原来的基础上改为感应上级的LRU替换策略。替换

策略的流程如图4.4所示。

Temp有效？

将temp作为被替换对象；

结束

开始

Temp的upperAccess的

size>1？

将temp作为被替换对象；

结束

temp=该组末尾的cacheline

temp=temp前面一个

cacheline

Temp不是该组队首的

cacheline？

将temp作为被替换对象；

结束

图4.4感应上级的LRU替换策略流程图

第四章缓存替换策略的优化

替换策略优先替换无效的cacheline，由于被无效的cacheline都会放入队尾，那么队尾如果是无

效的cacheline可以直接替换，如果不是再考虑其前面的cacheline，这时可以确定所有备选cacheline

都是有效的了，需要优先从中选出上级cache中没有的cacheline，即upperAccess的size=0的cacheline，

如果还找不到要替换的cacheline，说明所有cacheline在上级cache中都有，那么选择队尾的cacheline

输出。

4.3本章小结

本章重点介绍了本课题采用的cache性能优化方案，从整体逻辑上概括了该方案的主要思想，

进而分析了该方案的优点和可能的缺陷。并以第三章对GEM5模拟器代码的分析为基础，新增和修

改了cache部分的代码，完成了感应上级LRU替换策略在GEM5平台上的具体实现。具体新增或修

改内容包括增加upperAccess标志位用以记录上级cache的使用情况；上级cache使用信息的产生、

传递等维护机制；inclusivecache的实现等。

东南大学工程硕士学位论文

第五章优化替换策略后的测试结果与分析

本章以第三章对GEM5平台的分析和第四章的优化思路为基础，基于在GEM5模拟器平台搭建

的模型，通过SPEC2006处理器性能测试工具对优化前后的cache性能进行测试。本章将对cache模

型、测试工具、主要指标分别进行介绍，并对测试结果做一系列比较和分析。

5.1实验环境

为了有效验证本课题提出的优化方案是否有效，本文作者搭建了一个与当今主流高速缓存架构

类似的模拟器模型，并针对测试软件不同测试集的具体情况进行分组，以尽可能客观的分析本课题

的实际应用效果。

5.1.1模拟器中的cache结构

基于对目前市场主流的高性能处理器cache-memory架构的了解，本课题实验模型的cache结构

定为共三级cache，L1cache和L2cache为每个核私有，四个核共享L3cache。cache模型配置如表

5.1所示。

表5.1缓存模型配置

参数名称参数值

核数

流水线级数

指令TLBsize

数据TLBsize

L1指令Cache大小

32KB

L1指令Cache组相联路数

8way

L1数据Cache大小

32KB

L1数据Cache组相联路数

8way

L1MSHR深度

L2Cache大小

128KB

L2Cache组相联路数

L2MSHR深度

L3Cache大小

2MB

L3Cache组相联路数

16way

L3MSHR深度

预取无

上述缓存模型配置导的可视化结构图如图5.1所示。

东南大学工程硕士学位论文

Core2

L1dataL1ins

Core1

L1dataL1ins

Core3

L1dataL1ins

Core0

L1dataL1ins

Crossbar

图5.1缓存模型结构

5.1.2实验环境与测试集

本次测试所使用的宿主机的软硬件配置如表5.2所示。

表5.2宿主机软硬件配置

处理器

Intel(R)Xeon(R)****************

内存

32GbDDR3

操作系统

Ubuntu16.04.3LTS

编译器版本

gcc5.4

Python版本

Python2.7

GEM5版本

stable_2015_09_03

SPEC版本

SPECCPU2006v1.2

GEM5模拟器主要通过C++/python编写，源代码部分主要是C++语言，而配置相关的代码主要

由python语言编写，使用gcc5.4编译。

SPECCPU2006是SPEC(StandardPerformanceEvaluationCorporation)公司最初在2006年发布的

处理器性能测试套件，是业界最主流的处理器性能测试软件之一，经过十年间的多次迭代更新后更

加稳定可靠，v1.2版是其最新的版本。SPECCPU2006包含多个整数和浮点运算测试集。整数运算

测试包括编译器、解释器、文字处理器、国际象棋等测试集。浮点性能测试包括物理模拟、3D图形、

图像处理、计算化学等测试集[29][30]。更可贵的是，SPECCPU2006不仅仅可以测试实体机的性能，

还能在GEM5模拟器上构建SPECCPU2006基准测试，这非常有助于测试和分析处理器架构设计上

的问题。本课题的验证就使用GEM5平台，通过交叉编译的方式运行SPECCPU2006测试集，以其

结果为依据分析cache的性能与效率，并对本课题提出的优化方案的效果做出验证[31]。

5.1.3衡量cache性能和效率的主要指标

本课题实验主要跟踪记录GEM5平台在运行SPECCPU2006测试集过程中的cache命中率和

IPC[32]。

对于衡量命中率的方法，在这里引入MPKI(每千条指令的未命中率,MissrateperKiloInstruction)，

第五章优化替换策略后的测试结果与分析

如公式5.1所示。

MPKI=未命中次数

执行的指令总数

×1000

（5.1）

相较于传统的未命中比例(missrate)，MPKI数据更能反映不同应用场景下cache的命中效率。

举例来说，假如两个应用场景，分别各有1000条指令，其中第一个测试集中有900条都是运算指令，

只有100条指令需要访存，如果100条访存指令中有20次hit和80次miss，那么第一个测试集整

体的missrate就高达80%，而对应的MPKI为80。第二个测试集中运算和访存指令相当，500次访

存中有100次miss，那么第二个测试集的整体missrate则为10%，此时的MPKI为100。从这个例

子可以看出，第二个测试集的10%missrate是相对有效的数据，而第一个测试集80%的missrate数

据并不能真实反映cache的真实性能和效率。MPKI数据将指令数量的影响考虑进去，减少不同应用

环境对miss数据结果的干扰，更能说明测试场景对cache性能的需求。

此外本文还将着重对比IPC数据，IPC是衡量处理器性能的一个重要指标，如公式5.2所示。

IPC的值本质上就是每个时钟周期执行的平均指令数，它的高低代表着处理器的执行效率。

IPC=执行指令数

周期总数

（5.2）

5.2性能测试结果对比与分析

本小结内容按照IPC数据和MPKI数据为评判指标，并按照单核与四核测试分两部分比较优化

前后处理器模型的性能差异。

5.2.1单核测试及分析

由于SPECCPU2006中不同的测试程序数据和指令的需求量不同，所以不同测试程序的cache

missrate也会有比较大的差别[33]，因此要保证相对较多的测试程序样本。本文选择了8个有代表性

且能在GEM5平台下正常运行的测试项，用默认LRU下每次都单独在一个核里运行，而其他核都

处于空闲状态，来评估没有L3共享冲突的情况下本文方案的效果。以mcf测试为例，单核测试运行

界面如图5.2所示。

东南大学工程硕士学位论文

图5.2运行单核测试

运行结束后输出路径会产生文件，该文件里包含模拟器运行过程中的所有数据。根据

公式5.1，可以根据输出文件中的总miss数和总指令数，取其比值乘以1000即可得到相应的MPKI

数据。以mcf的L2cache为例，如图5.3所示，表示cpu0的L2cache的总miss数的项目为sys-

l_miss::total，共有220075268次，而分屏下层表示仿真过程中执行指令总数的

sim_insts项目数值为3368185927，则根据公式5.1：

L2MPKI=未命中次数

执行的指令总数

×1000=

220075268

3368185927

×1000≈65.34。

图5.3mcf单核运行结果

此外，可以从中直接得到mcf单核运行时的IPC数据大约为0.44，如图5.4所示。

图5.4mcf单核运行IPC

以此类推，类似于mcf测试数据的获取方式，统计出使用优化方案前单核测试程序的的L2cache

MPKI，L3cacheMPKI和IPC数据，如表5.3所示。根据数据可见，测试程序的CacheMPKI指标各

不相同，一般情况下MPKI越大的测试集，对应的IPC就越小，这是由于CacheMPKI越大，存储

第五章优化替换策略后的测试结果与分析

器访问指令造成的延时越长，那么每周期能完成的指令数就越小，当然MPKI与对应的IPC并非严

格的负相关，因为IPC还与测试程序本身的特征有关系（例如程序访问存储器的模式等）。

表5.3单核测试的L2cache和l3cache的MPKI

gccmcfhmmersjengh264refomnetppperlbenchxalancbmk

L2MPKI(次)9.7565.340.482.970.9534.731.0216.94

L3MPKI(次)7.4141.820.261.630.5119.100.809.15

IPC(条)1.190.441.981.351.880.752.181.28

5.2.1.1单核MPKI比较

使用了优化方案后L2MPKI的数据见表5.4。由于单核测试的重点是看L3cache减少了对L2

cache的inclusionvictim后，L2cache获得的收益，L3cache是由于L2cache的MPKI少了之后间

接提高性能的，因此，这里只分析了L2Cache的优化前后的数据进行对比。

表5.4单核测试的L2mpki优化前后数据

gccmcfhmmersjengh264refomnetppperlbenchxalancbmk

优化前L2MPKI(次)9.7565.340.482.970.9534.731.0216.94

优化后L2MPKI(次)9.5663.510.482.970.9533.621.0216.41

单核测试优化比例1.9%2.8%0.8%0.1%0.2%3.2%0.4%3.1%

根据上述数据获得了图5.5L2MPKI的优化收益，可以直观的看到本文方案带来的收益。

图5.5单核测试的L2MPKI优化提升比例

根据上述数据可以看出，本文方案对于单核测试程序的L2效率上是有提升的，但提高整体上不

是特别明显，最高收益是3.2%（omnetpp），而最低只有0.1%（这很可能是正常平台误差）。并且可

以看出，不同测试程序对于的L2cache效率的提升差异化明显，优化前MPKI越高的测试程序，L2

MPKI在优化后获得的提升更明显，这个也符合预期，因为越多的MPKI表示越大概率的inclusion

victim的产生，自然针对inclusionvictim的优化就越明显。从测试程序来看，就是原本L2MPKI大

的gcc，mcf，omnetpp和xalancbmk优化的比较明显；而hmmer，sjeng，h264ref和perbench的优化

0.0%

0.5%

1.0%

1.5%

2.0%

2.5%

3.0%

3.5%

gccmcfhmmersjengh264refomnetppperlbenchxalancbmk

单核L2mpki优化比例

东南大学工程硕士学位论文

不明显。

5.2.1.2单核IPC数据比较

根据5.2.1中介绍的计算方法，统计出独立运行每个测试集的IPC数据和优化提升比例分别如表

5.5所示。

表5.5单核测试优化前后的IPC数据

gccmcfhmmersjengh264refomnetppperlbenchxalancbmk

优化前IPC(条)1.190.441.981.351.880.752.181.28

优化后IPC(条)1.220.462.011.351.880.762.191.30

单核测试优化比例2.5%2.8%1.8%0%0.1%1.1%0.4%2.1%

根据上述数据获得了图5.6IPC的优化收益，可以直观的看到本文方案带来的收益。

图5.6单核测试IPC数据的提升比例

根据上述数据可以看出，测试程序的IPC的提升最高是2.8%（mcf）。另外IPC的优化程度按

照从大到小排序并不一定与L2MPKI一致，这也是预期之中的，正如前文提到的IPC还与测试程

序本身的特征有关系。

5.2.2四核测试及分析

根据上一节的测试分析可以看出，单核情况下，优化方案带来的收益并不是很高，因为方案只

优化了对于L3cache造成单一L2cache的inclusionvictim问题进行了优化。为了评估多核竞争共享

L3cache的情况下本文方案的优化程度，也进行了四核测试方案，即每个核同时运行一个测试程序。

四核同时运行四个测试项的运行界面如图5.7所示。

-0.5%

0.0%

0.5%

1.0%

1.5%

2.0%

2.5%

3.0%

gccmcfhmmersjengh264refomnetppperlbenchxalancbmk

单核测试IPC数据的提升比例

第五章优化替换策略后的测试结果与分析

图5.7运行四核测试

为了确保测试结果的严谨以及便于分析测试结果，避免测试集的差异导致测试结果失真，本课

题参考L3cacheMPKI将测试集分为三组进行测试。分别是高MPKI测试集的mix1组：mcf/omnetpp/

xalancbmk/gcc;高低MPKI测试集各两个的mix2组：mcf/omntepp/hmmer/h264ref;低MPKI测试

集组成的mix3组：hmmer/h264ref/perlbench/sjeng：。每组分别独立在一个core里运行，每个核私

有L1/L2cache，四核共享L3cache，观察默认替换策略下和优化替换策略后L2cache和L3cache的

命中情况(MKIPI数据)以及整个系统的运行效率(IPC数据)。

5.2.2.1多核MPKI比较

由于单核测试时无法验证多核多任务时L3cache在相对拥挤情况下的优化效果，5.1.3中介绍的

三个测试组的四核多测试项混合测试结果和优化提升比例如表5.6和图5.8，四核多测试项混合测试

结果的计算方法与本文5.2.1中介绍的相同，此处不再赘述。

表5.6四核测试的L3mpki优化前后数据

优化前L3MPKI(次)优化后L3MPKI(次)优化提升比例

MIX1(mcf,omn,xal,gcc)77.2570.488.8%

MIX2(mcf,omn,hmm,h264)69.8666.075.4%

MIX3(hmm,h264,perl,sjeng)1.891.870.8%

图5.8四核测试的L3MPKI提升比例

0.0%

2.0%

4.0%

6.0%

8.0%

10.0%

MIX1(mcf,omn,xal,gcc)MIX2(mcf,omn,hmm,h264)MIX3(hmm,h264,perl,sjeng)

四核测试的L3MPKI提升比例

东南大学工程硕士学位论文

三个测试组的L3cache的MPKI都有不同幅度的提升，而且类似于单核测试的结果，MPKI的

提升幅度与每组测试集优化前的MPKI基数是正相关的。具体分析，引入感应上级的LRU替换策

略后，victimcache的问题很大程度上解决，而inclusionvictim问题的发生是会同时造成L2cache

效率更差，而L3cache是间接受到影响的，因此优化后L2和L3的MPKI数据会同时提高。此

外，多核测试且负载更高的时候，由于是多核共享的L3Cache，L3Cache会接收到更多的请求，

MPKI也会更多更高，L3cache需要LRU替换的机会也就更多，victimcache问题解决带来的命中

率改善就越发明显，这就导致了方案提升数据中MIX1组的高于MIX2组，更远高于MIX3组。

5.2.2.2多核IPC数据比较

多核多测试集下的IPC数据如表5.7和图5.9。为了便于直观比较，此时的IPC数值为四个核

四个IPC数据的总和。

表5.7四核测试优化前后的IPC数据

优化前IPC(条)优化后IPC(条)优化提升比例

MIX1(mcf,omn,xal,gcc)2.162.317.2%

MIX2(mcf,omn,hmm,h264)2.983.104.1%

MIX3(hmm,h264,perl,sjeng)4.144.150.2%

图5.9四核测试IPC数据的提升比例

四核多测试集同时运行的IPC数据情况与MPKI的提升类似，IPC数据由于victimcache问题

导致的开销减少提高了处理器的整体效率。而MIX1测试组由于L2或L3MPKI指标最高，inclu-

sionvictim导致的miss后造成的访存延迟越大，带来的处理器效率提升也就最多，因此优化带来的

收益也就越大，程序性能提升7.2%。其他两组因为L2或L3MPKI相对较少，触发inclusionVictim

的机会更少，因此优化替换策略所带来的效率提升也就相对较少。

0.0%

1.0%

2.0%

3.0%

4.0%

5.0%

6.0%

7.0%

8.0%

MIX1(mcf,omn,xal,gcc)MIX2(mcf,omn,hmm,h264)MIX3(hmm,h264,perl,sjeng)

四核测试的IPC提升

第五章优化替换策略后的测试结果与分析

5.2.3测试结果与预期指标对比

本章按照1.3.2中的设计指标，搭建了具有三级高速缓存的缓存模型，三级cache的大小分别

为L1cache32KB，L2cache128KB，L3cache2MB。并测试了加入感应上级的LRU替换策略前后

单核和多核并行时LLC的MPKI和整个处理器模型的IPC。相比于前文MPKI降低至少3%，处理

器的IPC能够提高至少1%的目标，本章的测试结果为单核测试下的IPC平均提升1.35%，L2

cacheMPKI平均降低1.5%。优化后多核测试的IPC数据平均提升3.83%，L3cacheMPKI平均降低

5.0%。直观的对比结果如表5.8和图5.10。

表5.8测试结果与预期指标对比

MPKI降低比例IPC提高比例

目标值

3%1%

单核结果

1.5%1.35%

四核结果

5.0%3.83%

图5.10测试结果与预期指标对比

由对比结果可以看出，单核和四核情况下，IPC的提升比例都达到了超过1%的预期指标。在

cachemiss的减少程度上，四核L3MPKI的降低比例远多于预期指标，而单核下的MPKI因为单核

无竞争而不及预期，也印证了前文中提到的多核环境下LLC竞争现象能够使本方案发挥更大作用

的观点。总体而言，本章的测试证明了感应上级的LRU替换策略的加入有效缓解了inclusivecache

victim现象，尤其在多核应用场景下对处理器的高速缓存性能和处理器整体效率有一定帮助。

预期指标单核结果四核结果

测试结果与预期指标对比

MKPI降低比例IPC提高比例

东南大学工程硕士学位论文

5.3本章小结

本章主要基于第三章对GEM5模拟器的分析和第四章对缓存替换算法的优化方案，在添加了感

应上级LRU替换策略的GEM5模拟器平台上使用SPECCPU2006进行测试，比较替换策略优化前

后模型的性能。得到优化前后的MPKI和IPC数据并以此为依据进行比较和分析，单核测试下的IPC

平均提升1.35%，L2cacheMPKI平均降低1.5%。优化后多核测试的IPC数据平均提升3.83%，L3

cacheMPKI平均降低5.0%。实验结果显著高于设立的指标，MPKI的降低证实了感应上级的LRU

替换策略对解决inclusivevictim问题有所帮助，而IPC的提高也说明了本方案对处理器整体性能也

带来了一定的提升。

第六章总结与展望

6.1总结

本论文主要基于GEM5处理器模拟器软件平台，研究并搭建了优化的感应上级的LRU替换策

略的处理器高速缓存模型，并加以测试与验证。主要工作有以下几个方面：

(1)研究当前主流的多核处理器cache-memory结构，对高速缓存的包含策略、替换策略以及

inclusivecachevictim问题进行剖析，对业界已有的TLH/ECI/QBS优化方案的优缺点进行比较和

分析，确定了提高下级cache对上级cache使用情况的了解程度为本课题的主要切入点，提出基于

upperAccess标志位的感应上级的LRU替换策略。

(2)分析GEM5模拟器cache部分的代码，以原架构为基础进行修改和优化，在L3cache中增

加upperAccess标志位用以记录上级cache的使用情况，增加上级cache使用信息的产生、传递等维

护机制，修改LRU替换策略为基于upperAccess标志位状态的替换顺序，从而在GEM5模拟器平

台上具体实现了本课题的优化方案。

(3)在添加了感应上级LRU替换策略的GEM5模拟器平台上使用SPECCPU2006进行测试，

比较替换策略优化前后模型的性能。得到优化前后的MPKI和IPC数据并以此为依据进行比较和分

析，单核测试下的IPC平均提升1.35%，L2cacheMPKI平均降低1.5%。优化后多核测试的IPC

数据平均提升3.83%，L3cacheMPKI平均降低5.0%。实验结果显著高于本文设立的指标，MPKI

的降低证实了感应上级的LRU替换策略对解决inclusivevictim问题有所帮助，而IPC的提高也说

明了本方案对处理器整体性能也带来了一定的提升。

6.2展望

本文在GEM5模拟器平台的巨人肩膀上，完成了感应上级的LRU替换策略优化方案的实现与

验证，但是未来还可以在以下几个方向上进行进一步研究：

(1)本方案目前是以四核为基础的架构下进行验证的，如果在8核或者16核的环境下，更多核

共用LLC必然会导致更严重的LLC使用竞争现象。此时使用本方案的替换策略是否会带来更为明

显的性能提升效果，还可以测试增加到多少核的时候性能提升的效果会达到临界点。

(2)本文基于软件模拟器平台，如果进一步到硬件实现，还需要大量的量化分析评估工作，比

如硬件实现时更多处理器核心导致的大量标志位的芯片面积占用和标志位的维护开销等。

东南大学工程硕士学位论文

(3)本文的出发点是解决inclusivecache的victim现象，但其实也在某种程度上缓解了多核处

理器中LLC的竞争问题，而对于多核共享LLC竞争问题，业界上在近两年也不断推出新技术，比

如INTEL公司的RDT（ResourceDirectorTechnology）的CAT（CacheAllocationTechnology）技

术。后续工作可以对比本方案和业界主流方案的优化效果。

参考文献

[1]张晨曦.计算机体系结构教程[M]清华大学出版社.2009.7-10

[2]唐塑飞.计算机组成原理[M]高等教育出版社.2008

[3]VikashRai，oreProcessors-ANecessity[J]ProquestDiscoveryGuides2008

[4]胡伟武.计算机体系结构[M]清华大学出版社.2011

[5]杨际祥,谭国真,王荣生.多核软件的几个关键问题及其研究进展[J].电子学报,2010,38(9):2140-

2146.

[6]DavidCuller,erArchitecture:AQuantitativeApproach[M]第六版.MorganK-

offmann出版社2017

[7]DoweckJ,KaoWF,LuKY,6th-GenerationIntelCore:NewMicroarchitectureCodeN-

amedSkylake[J].IEEEMicro,2017,37(2):52-62.

[8]SinghT,SchaeferA,RangarajanS,:AnEnergy-EfficientHigh-Performancex86Core[J].I-

EEEJournalofSolid-StateCircuits,2017,53(1):102-114.

[9]胡伟武,张福新,李祖松.龙芯2号处理器设计和性能分析[J].计算机研究与发展,2006,43(6).

[10]Jaleel,Aamer,Borch,Eric,Bhandaru,Malini,ingNon-InclusiveCachePerformancewithI-

nclusiveCaches:TemporalLocalityAware(TLA)CacheManagementPolicies[C].201043rdAnnual

IEEE/ACMInternationalSymposiumonMicroarchitecture.2010:151-162.

[11]GangyongJia,GuangjieHan,HaoWang,arecachereplacementpolicyinsharedlast-level

cacheforhybridmemorybadfogcomputing[J].EnterpriInformationSystems,2018,12(4):435-451

DOI:10.1080/17517575.2017.1295321.

[12]nedDataCacheWithMultiplePortsAndProcessorWithLoad/SoreUnitSelecing

OnlyLoadOrStoreOperationsForConcurrentProssing[P]USA.6202139B1.2001

[13]'s24-corePower9chip:5thingsyouneedtoknow[G]PCWorld,2016-08-23

[14]邹代红.基于双端口RAM的数据Cache的研究与实现[D]西安.西北工业大学.2007

[15]崔磊.数据Cache存储体的设计与验证[D].长沙.国防科技大学.2006

[16]SolihinYanFundamentalsofParallelMulticoreArchitecture[M]CRCPress.146–150,2016

[17]王齐浅谈CacheMemory[EB/OL]/s/blog_,2011

[18]石文强.多核Cache替换策略模型研究[D]国防科学技术大学2011

[19]fDifferentCacheLineReplacementAlgorithmsinEmbeddedSystems[D]AR-

MFranceSAS2007

[20]O'Neil,ElizabethJ.;O'Neil,-KPageReplacementAlgorithmforDatabaDisk

Buffering[J]MODInt':10.1145/17003

5.170081

[21]KamilKedzierski;ngCachePartitioningAlgorithmstoPudo-LRUReplace-

mentPolicies[EB/OL]/ipdps2010/ipdps2010-slides/ssion-22/

2010

[22]KedzierskiK,MoretoM,CazorlaFJ,ngcachepartitioningalgorithmstopudo-LRU

东南大学工程硕士学位论文

replacementpolicies[J].IEEE,2010:1-12.

[23]DingC,ShaoZ,eNotesinComputerScienceNetworkandParallelComputing

cientSimulationAlgorithmforCacheofRandomReplacementPolicy[J].2010,

10.1007/978-3-642-15672-4(Chapter13):144-154.

[24]Vakil-GhahaniA,Mahdizadeh-ShahriS,Lotfi-NaminMR,eplacementPolicyBad

onExpectedHitCount[J].IEEEComputerArchitectureLetters,2017:1-1.

[25]GutierrezA,PusdrisJ,DreslinskiRG,soferrorinfull-systemsimulation[C]2014IEEE

,2014.13-22

[26]EndoFA,Couroussé,Damien,CharlesHP.[ACMPressthe2015Workshop-Amsterdam,Holland

(2015.01.19-2015.01.21)]Proceedingsofthe2015WorkshoponRapidSimulationandPerformance

EvaluationMethodsandTools-RAPIDO15-Micro-architecturalsimulationofembeddedcoreheer-

ogeneitywithgem5andMcPAT[J].2015:1-6.

[27]ClassicMemorySystem[EB/OL]/Classic_Memory_System,2017.

[28]MemorySysteminGEM5[EB/OL]/docs/html/20-

17．

[29]LiS,ChengB,GaoX,manceCharacterizationofSPECCPU2006BenchmarksonIntel

andAMDPlatform[C].InternationalWorkshoponEducationTechnology&-

E,2009.

[30]SPEC2006[EB/OL]/cpu2006,2017

[31]YeD,RayJ,HarleC,manceCharacterizationofSPECCPU2006IntegerBenchmarks

onx86-64Architecture[C].Proceedingsofthe2006IEEEInternationalSymposiumonWorkloadCh-

aracterization,IISWC2006,October25-27,2006,SanJo,California,,2006.

[32]ngandAnalysisofaCacheCoherentInterconnect[D]EindhovenUniversityofT-

echnology,2012

[33]HameedF,KhanAA,manceandEnergy-EfficientDesignofSTT-RAMLastLe-

velCache[J].IEEETransactionsonVeryLargeScaleIntegration(VLSI)Systems,2018:1-14.

致谢

回顾在职读研期间，自始至终得到我的导师李冰老师无微不至的关心，从开题选题到论文的最

终完成，都是李老师的帮助督促之下得到顺利完成。李老师始终秉承其以身作则的传统，以严谨治

学的作风和平易待人的态度，不仅在学习中，更在生活的为人处事中我也因此获益良多，值此课题

结束之际，谨向李老师表以最诚挚的谢意。

同时，我非常感谢我的校外导师冯春阳老师，以及东南大学无锡分校的刘勇老师，感谢他们在

我论文课题研究期间给予无私的帮助和鼓励。

非常感谢在课题研究期间给与我帮助的同事们，他们不厌其烦的配合我处理搭建平台过程中遇

到的各种问题，感谢公司为我提供了一个良好的学习和研发环境。

此外，还要感谢我的父母和我的妻子，在我忙于论文无法分心的时候给予我理解和支持。

最后感谢东南大学多年的培养。感谢曾经教育和帮助我的所有老师和同学。衷心感谢百忙之中

抽出时间参加论文评阅和评议的各位专家学者，感谢为审阅本文所付出的辛勤劳动，论文肯定还有

很多不足之处，期待批评和指导，谢谢！

本文发布于:2022-12-28 12:28:34，感谢您对本站的认可！

本文链接：http://www.wtabcd.cn/fanwen/fan/90/46626.html

上一篇：gotham

下一篇：agatha什么意思

标签：inclusive

留言与评论（共有 0 条评论）