2.4 Cache Block的替换算法2

2023-10-25 17:19
文章标签 2.4 cache block 替换算法

本文主要是介绍2.4 Cache Block的替换算法2,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

对页面5的访问并没有在Cache中命中,此时需要一个Free页面进行页面替换。LIRS算法首先淘汰在Q中页面7,同时将这页面在S中的状态更改为不在Cache命中;之后页面8S落到Q中,状态从LIR迁移到HIR,但是这个页面仍在Cache中,需要重新压栈;页面5没有在Cache中命中,但是在S中命中,需要将其移出后重新压栈,状态改变为在Cache中命中。本篇不再介绍LIRS算法的实现细节,对此有兴趣的读者可以参照[40][41]

而后出现的Clock-Pro算法是LIRS思想在Clock算法中的体现。Clock-ProLIRS都为LIRS类算法。其中Clock-Pro算法实现开销更小,适用于操作系统的Virtual MemoryManagement,并得到了广泛的应用,LinuxNetBSD使用了该算法;LIRS算法适用于I/O存储领域中,mySQLApache Derby使用了该算法。LIRS算法较为完美地解决了Weak Access Locality AccessPattern的处理。在LIRS算法出现之后,还有许多页面替换算法,这些后继算法的陆续出现,一次又一次证明了尚未出现更好的算法在这些领域上超越LIRS算法。

LIRSClock-Pro算法在这个领域的地位相当于Two-Level Adaptive BranchPredictionBranch Prediction中的地位。在详细研读[40][42]的细节之后,发现更多的是作者的实践过程。LIRS算法类不是空想而得,是在试错了99条路之后的发现。这是创新的必由之路。

在掌握必要的基础知识后,也许我们最应该做的并不是研读他人的书籍和论文,更多的是去实践。经历了这些艰辛的实践过程,才会有真正的自信。这个自信不是盲从的排他,是能够容纳更多的声音,尽管发出这个声音的人你是如此厌恶。

与微架构设计相比,在操作系统和应用层面可以有更多的资源和更多的时间,使用更优的页面替换算法。虽然在操作系统和应用层面对资源和时间依然敏感,但是在这个层面上使用的再少的资源和再短的时间放到微架构中都是无比巨大。在微架构的设计中,很多在操作系统和应用层面适用的算法是不能考虑的。

假设一个CPU的主频为3.3GHz,在每一个Cycle只有300ps的情况之下,很多在操作系统层面可以使用的优秀算法不会有充足的时间运行。虽然LRU算法在SimplicityAdaptability上依然有其优势,在微架构的设计中依然没有得到广泛的应用。即便是LRU算法,CacheWays Number较大的情况之下也并不容易快速实现。当Way Number大于4后,LRU算法使用的Link Lists方式所带来的延时是Silicon Design不能考虑的实现方式。更糟糕的是,随着Way Number的增加,LRU算法需要使用更多的状态位。

下文讨论的Cache Block替换算法针对N-Way Set Associative组织方式。在这种情况下,Cache由多个Set组成,存储器访问命中其他Set时,不会影响当前Set的页面更换策略,所谓的替换操作是以Set为单位进行的。为简化起见,假设下文中出现的所有存储器访问都是针对同一个Set,不再考虑访问其他Set的情况。

通常情况,在N-Way SetAssociativeCache中,快速实现Full LRU最多需要N×(N-1)/2个不相互冗余的状态位,理论上的最小值是Floor(LOG2(N!))个状态位[23]。因此当Way Number大于4之后,所需要的状态位不是硬件能够轻易负担的,所需要的计算时间不是微架构能够忍受的。这使得更多的微架构选用了PLRU算法进行Cache BlockReplacement

LRU算法相比,PLRU算法使用了更少的存储空间,查找需要替换页面的时间也较短,而且从Miss Rate指标的考量上与LRU算法较为类似,在某些特殊场景中甚至会优于LRU算法[36],从而在微架构的设计中得到了大规模的应用。

PLRU算法有两种实现方式,分别为MRU-BasedTree-Based方式。MRU-Based PLRU的实现方式是为每一个Cache Block设置一个MRU Bit,存储器访问命中时,该位将设置为1,表示当前Cache Block最近进行过访问。当因为Cache Miss而进行Replacement

这篇关于2.4 Cache Block的替换算法2的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/284039

相关文章

[Linux Kernel Block Layer第一篇] block layer架构设计

目录 1. single queue架构 2. multi-queue架构(blk-mq)  3. 问题 随着SSD快速存储设备的发展,内核社区越发发现,存储的性能瓶颈从硬件存储设备转移到了内核block layer,主要因为当时的内核block layer是single hw queue的架构,导致cpu锁竞争问题严重,本文先提纲挈领的介绍内核block layer的架构演进,然

block对变量捕获的方式

之前见很多文章对block捕获变量的方法,会进行诸如此类的描述:“block会捕获被引用的变量, 并对其进行copy操作, 因此, 可能会导致其引用计数加1,如果处理不好, 可能因循环引用导致内存泄漏。” 实际上, 这种说法并不严谨。block对变量的捕获, 根据变量类型的不同,会采用不同的捕获方式。 (1)静态或者全局变量, 在block中直接是指针传递的方式传入block中,对其进行的操作

Linux block_device gendisk和hd_struct到底是个啥关系

本文的源码版本是Linux 5.15版本,有图有真相: 1.先从块设备驱动说起 安卓平台有一个非常典型和重要的块设备驱动:zram,我们来看一下zram这个块设备驱动加载初始化和swapon的逻辑,完整梳理完这个逻辑将对Linux块设备驱动模型有深入的理解。 zram驱动加载的时候会调用zram_add函数,源码如下: 1887/*1888 * Allocate and initia

[项目][CMP][Thread Cache]详细讲解

目录 1.设计&结构2.申请内存3.释放内存4.框架 1.设计&结构 Thread Cache是哈希桶结构,每个桶是一个按桶位置映射大小的内存块对象的自由链表 每个线程都会有一个Thread Cache对象,这样每个线程在这里获取对象和释放对象时是无锁的 TLS – Thread Local Strorage Linux gcc下TLSWindows vs下TLS

[项目][CMP][Central Cache]详细讲解

目录 1.设计&结构2.申请内存3.释放内存4.框架 1.设计&结构 Central Cache也是一个哈希桶结构,它的哈希桶的映射关系跟Thread Cache是一样的不同的是它的每个哈希桶位置挂的是SpanList链表结构(带头双向循环链表),不过每个映射桶下面的span中的大内存块被按映射关系切成了一个个小内存块对象挂在span的自由链表中 8Byte映射位置下面挂的是

Oracle - ORA-01789: Query block has incorrect number of result columns

一、原因     这个错误一般是在执行表之间的相加(union),相减(minus)等SQL语句时,两个个查询块具有不一致的结果列数所导致的。 二、方案     只要将两段SQL语句的列数调整为一致就可以解决。使用union时,要注意数据库字段的格式要一致,如varchar和nvarchar是不一样的。

LRU算法 - LRU Cache

这个是比较经典的LRU(Least recently used,最近最少使用)算法,算法根据数据的历史访问记录来进行淘汰数据,其核心思想是“如果数据最近被访问过,那么将来被访问的几率也更高”。 一般应用在缓存替换策略中。其中的”使用”包括访问get和更新set。 LRU算法 LRU是Least Recently Used 近期最少使用算法。内存管理的一种页面置换算法,对于在内存中但又不用的

Fast Image Cache

https://github.com/path/FastImageCache   Fast Image Cache is an efficient, persistent, and—above all—fast way to store and retrieve images in your iOS application. Part of any good iOS applica

ARC下的block导致的循环引用问题解析

引言 使用block已经有一段时间了,感觉自己了解的还行,但是几天前看到CocoaChina上一个关于block的小测试主题:【小测试】你真的知道blocks在Objective-C中是怎么工作的吗?,发现竟然做错了几道,才知道自己想当然的理解是错误的,所以抽时间学习了下,并且通过一些测试代码进行测试,产生这篇博客。 Block简介(copy一段) Block作为C语言的扩展,并不是高新

前端面试:对BFC规范(块级格式化上下文:block formatting context)的理解

块级格式化上下文(BFC)是一个独立的渲染区域,具有特定的布局规则。理解BFC对于前端开发非常重要,因为它影响元素的布局和定位。以下是对BFC的一些关键理解: 定义:BFC是一个HTML文档中的部分区域,内部的元素在该区域内独立于外部元素进行布局。BFC的创建可以通过特定的CSS属性,如overflow(非visible)、display: flow-root、position: absolut