其他分享
首页 > 其他分享> > 3.6.5 Cache写策略

3.6.5 Cache写策略

作者:互联网

 

 

赛叩 (☆^O^☆) (* ̄︶ ̄)

 好在这一小节中我们要解决cache部分的最后一个内容,就是cash的一些策略,之前我们提出了这样三个来解决的问题,前两个问题我们已经解决了,那还剩最后一个问题就是说cash当中保存的只是主整理的数据的一个副本,那么CPU对cash里的数据进行写操作修改了里面的数据之后,如何保持储存和cash的数据一致性呢?那这就是cash的写策略要探讨的问题,那我们会分为两种情况来探讨写的策略,第1种情况如果说此时CPU要写的那个存储单元被命中也就是已经存在开始里边的话,那这种情况如何处理?我们可以有两种方法,一种叫全息法,一种叫写回法,而第2种情况,如果说此时CPU它想写的地址没有那么我们就会有两种处理的策略分配法和非法操作呢这是因为我们要解决的事数据一致性的问题如果说操操作还是无论发生了。这是因为我们要解决的是cash和储存数据一致性的问题,如果说CPU进行的是读操作而不是写操作,那么无论是读命中还是读不命中,无论发生哪种情况,只要是读操作就一定不会导致数据不一致的问题,所以在这一小节中我们只会探讨CPU进行写操作的时候,有可能发生了各种情况好,那首先来看,第1种情况就是CPU要对某一个地址进行斜,并且这个地址所对应的主存款已经被调入case当中发生了运作的情况,那在这种情况下我们会有两种处理的策略,第1种策略叫做写回法,那我们结合之前的小结给出了这个具体的例子,假设此时0号主存款已经被调入到了这个地方,然后紫色的这个主存块也被调入开始当中,那假设此时CPU要进行写操作的这个地址刚好是处于0号,也就是绿色这个主城快它所对应的地址范围,那如何采用写回法,就意味着CPU只会往cache当中的这个数据副本着写入相应的数据数据模板就发生了。淘汰的时候我们才会把它所对应的地址范围,那如果采用写回法就意味着CPU只会往cache当中的这个数据副本着写入相应的数据,那这个时候储存的数据补本和cache里的数据副本就发生了不一致的情况,但是这种不一致,我们只有在第3个cash行被淘汰的时候,我们才会把整个car厂里存储的这一整块的数据全部统一的写回储存,那另一个方面对于紫色这一块数据如果整个过程他都没有被修改过的话,那么当这个开始快被替换的时候,我们不需要把这个开始快写回组织,那这样的话我们就可以节省一些写回的时间,所以为了让硬件能够区分哪个太长的数据被修改过,哪个没有被修改过,所以我们还需要给每一个菜市场增加一个所谓的脏类的信息当一个数据快被修改之后我们需要把这个场所张玮把它设为一淘汰某一个长的时候就可以知道这个需要而到底应该。那什么的位置,我们又可以根据标记来判断好,所以采用写回法可以使CPU的访存次数减小,从而节省写操作所需要的时间,但是这种方式又存在数据不一致的隐患好,接下来看第2种方法叫做全写法,又叫写直通法,如果咱们这种方法那么就意味着当CPU对cash写命重的时候,它除了会把数据写往class之外,同时CPU也要往储存对应的存储单元写入相应的数据,那从这种方法就可以保证它所组成的数据基本上都能够保持一致。另外刚开始你的数据被淘汰的时候后,我们也不需要像之前那样写会储存,因为这两边的数据随时都是保持一致的好,那采用这种方法就意味着CPU每一次进行写操作的时候,除了访问cash之外也需要进行访存,那么访存次数增加就会导致CPU写操作的这个速度变慢他背了减少次数我们通常可以采用这样的优化策略一个所谓的也是用来制造的制造这意味着他背了减少次数我们通常可以采用这样的优化策略一个所谓的也是用来制造的制造这意味着对。防弹为了减少CPU方程的次数,我们通常可以采用这样的优化策略,我们可以增加一个所谓的写缓冲,那这个写缓冲也是用sm来制造的,用S room制造就意味着对写缓冲的读和写操作会比较快,那我们可以把它看作是一个先进先出的队列好来看一下如何使用当CPU对某一个地址进行写操作,并且这些地址命中的时候,CPU首先会向cash当中写入这个数据,另外CPU也会往切换功率启动相应的数据好,接下来假设CPU要往紫色的这一块写入进去,那同样的也会把这一块的内容把它写到这个写缓冲力,那由于写缓冲是用srm实现的,所以CPU对写缓冲的写操作要比直接往主持里面写要快得多,完了接下来CPU就可以去干其他的事情,比如说啊,会进行连续的好几次独操作,那么当CPU干其他事情的这期间又会有一个专门的控制电路来负责把写缓冲力写入的这些数据把它同步到主城里边这种方式那么当我们。其他事情的这个期间又会有一个专门的控制电路来负责把鞋款处理写入的这些数据把它同步到主城里面,那糖的如果采用这种方式,那么当我们淘汰某一个糖的时候,也不需要把这个看长的数据写回主存,那增加了写缓冲之后,可以使得CPU的写操作写的速度会变得很快,如果CPU的写操作不频繁的话,那么想这种策略效果会很好,而如果说CPU的写操作很频繁,那由于我们这个写缓冲它的容量是有限的,所以如果写操作很多,那么就会导致写缓冲饱和那当写缓冲,饱和之后CPU就必须阻塞等待,等他有空位再继续往里面写好那这就是权宪法,那到目前为止,我们探讨的是当CPU脚写的那个地址,可以民众的情况下,我们可以采取的两种策略,接下来我们再来看,当CPU要写的地址,不命中的情况下可以采取的策略,那第1种处理的方法叫做写分配法,就是说当CPU此时要访问的这个地址没有命中,那么如果采用的是写分配法。要写的地址,不命中的情况下,可以采取的策略,那第1种处理的方法叫做写分配法,就是说当CPU此时要访问的这个地址没有命中,那么如果采用的是写分配法,我们就会先把CPU当前要写的这一块的数据先把它调到cash当中,然后CPU再对cash进行写操作,也就是说储存里的这块数据保持不动CPU,只是修改了它的数据副本,那显然这种方式比较适合和我们之前提到的写回法配合着使用,也就是当这个态势快被淘汰的时候,才把这一整块的内容把它同步回主城里面,好那就是写分配法,通常和写回法配合着使用好再看,第2种处理方式叫做非写分配法,就只当CP想要写的地址没有命中的时候就会直接往而不会把这一块的内容非法一般来说会搭配着之前提到的写法来使用这种方法的话就意味着只有cd只进行操作读操作。写操作非民众那么CPU会直接写,而不会把这一块deal开始好,那这就是写操作不命中的情况下,就意味着只有CPU对某一个地址进行读操作读,操作未命中的情况下,才会把相应的主存块调入开始,而如果是写操作非常直接写,而不会把这一块的开始好,那这就是写操作不命中的情况下可以采取的两种策略,一种叫写分配法,一种叫飞写分配法,那现在我们。分配法一种叫诙谐分配法,那现在我们使用的计算机通常会从多级开始的结构最接近CPU的这起开始编号是L1,然后往下一级是L2,因为一些CPU或者L33级开始,那越接近CPU的速度会越快,但是容量会越小,因为成本会越高,而越远离CPU的,它的速度越慢容量也会越大,比如我们之前给出的这个截图可以看到啊,这是储存储存这一级的读写速度,这已经写出来了,然后I59300H这个CPU它是由三级开始,L1,L2,L3那最靠近CPU的L1这节课开始它的读写的速度几乎可以到1000GB这样的一个量级,而第2级的开始,它的读写速度差不多,就是比I一更慢一半对了再补充一下,我们之前也说过,cash里边保存的是储存里的某些数据,一小部分数据的副本那更高级更快速的开始,他所保存的数据又是更低一级开始的一小部分数据的副本,因此在各级开始之间同样存在数据一致性的问题。快速的开始它所保存的数据又是更低一级cash的一小部分数据的副本,因此在各级开始之间同样存在数据一致性的问题,那既然是要保证数据的一致性,因此就可以使用我们之前介绍的两种方法,各级开始之间采用的是全写法,加上非写分配法儿cache和主存之间通常会使用写回法加上写分配法,用这样的方式来保证数据的一致性好,那这一部分内容作一个简要的了解即可,那大家也可以去自己的windows电脑的任务管理器去看一下性能,这个夜间在这个地方你可以看到自己的CPU的一个详细的信息,就是他有几集的开始,每一集的开始重量是多少,这些信息大家可以去看一下,好的那这些小学生我们介绍了开始写,特别从而解决了cache与主存之间数据一致性的问题刚写的地址可以采取策略可以采取分类法和分配方式分配和使用而非写法。啊和写回法这两种策略而当写不命中的时候,可以采取写分配法和非写分配法这样的两种处理方式,那通常写分配法和写回法会配合着使用,而非写着分配法会和全写法配合着使用,那在这里解决,最后我们也简单的介绍了多级开始,本质上各级开始的作用和cash与主存之间的作用其实都是一样的,都是为了尽可能的降低成本,但是同时又尽可能的提升CPU的运行速度,那个集开始之间的数据同步通常会采用全写法配合非写分配法这样的方式来解决,而cache和主存之间通常采用写回法和写法法来解决数据一致性的问题,好得那么到目前为止,我们就解决了在cash的第1个消息当中提出的这三个问题,第1个问题如何区分cash和储存他们之间数据块的对应关系,这就是cash和储存的映射方式所要探讨的问题,分为全相连映射,直接映射和组相连映射然后再上学了满了之后我们应该怎么办我们介绍了其中最常用的应该。相连映射直接映射和组相联映射,然后在上一个小节当中我们又解决了,当cash满了之后,我们应该怎么办这样的一个问题,我们介绍了4种替换算法,其中最常用的应该是liu,也就是最近最久没使用算法,而这一小节中我们又解决了第3个问题,这是cash和储存当中数据一致性的问题,好的那么以上就是关于cash的相关考点。

标签:策略,分配,Cache,cash,我们,3.6,操作,数据,CPU
来源: https://blog.csdn.net/m0_45359314/article/details/110009484