以ARM Cortex-A55/A53为例分析 L1/L2/L3 cache所支持的写策略(write-back/wirte-through,写通和写回)

2024-03-06 23:20

本文主要是介绍以ARM Cortex-A55/A53为例分析 L1/L2/L3 cache所支持的写策略(write-back/wirte-through,写通和写回),希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

在文章 ARM 中缓存维护策略:Allocate policy(读分配/写分配),Write policy(写通/写回)以及replacement policy基础知识中,笔者介绍了ARM cache的Write policy(写通/写回)。今天我们以ARM Cortex-A55和A53为例,具体分析各级cache(L1/L2/L3 )对Write policy(写通/写回)的支持情况。

Cortex-A55/A53

  • 一,Cortex-A53 处理器
  • 二,Cortex-A55 处理器

一,Cortex-A53 处理器

Cortex-A53 处理器支持 L1 cache(instruction cache 和 data cache)以及L2 cache (unified cache)。

Cortex-A53处理器将缓存同步逻辑简化成了如下的内存类型:

  • 当内存类型为nner Write-Back 和Outer Write-Back 时,数据可以被缓存到 L1 Data cache 以及L2 cache中。
  • 当内存类型为Inner Write-Through时,Cortex-A53会将Inner Write-Through降级为Non-cacheable
  • 当内存类型为Outer Write-Through 或者 Outer Non-cacheable时,也会被Cortex-A53降级为Non-cacheable,就是内存的inner属性为Write-Back。
    上述规则如何理解呢?

就是说Cortex-A53处理器的L1 data cache以及L2 cache都不支持Write-Through策略,当处理器访问内存类型为Write-Through的数据时,这些数据并不会经过L1 data cache和L2。
至于L1 instruction cache,对于指令数据,处理器只是读取,并不会写,所以cache 的写策略对指令缓存不起作用。

笔者在文章 关于cache maintenance 操作的四个寄存器(CTR,CLIDR,CSSELR,CCSIDR)解析中介绍过 CCSIDR寄存器,在访问CCSIDR之前,必须先在CSSELR寄存器中写入正确的值, 与CSSELR相对应,会根据CSSELR中的内容,显示指定cache的cache line大小、way的数量以及set的数量。

在这里插入图片描述

不仅如此,CCSIDR还提供了四个状态位:WT、WB、RA以及WA:
在这里插入图片描述
通过这四个状态位,我们可以知道当前cache所支持的读分配策略以及写策略。
从WT始终为0也可以知道:Cortex-A53的所有级别的cacahe都不支持 Write-Through策略。

二,Cortex-A55 处理器

Cortex-A53 处理器支持 L1 cache(instruction cache 和 data cache),L2 cache (unified cache)以及L3 cache。
Cortex-A55处理器也将缓存同步逻辑简化成了如下的内存类型:

  • 当内存类型为Inner Write-Back 或者 Outer Write-Back 时,该内存上的数据才会被缓存到 L1 data cache 以及L2 cache中
  • 当内存类型为其他类型(包括 Write-Through)时,都会被视为Non-cacheable,即都不会被缓存。

所以Cortex-A55处理器对Write-Through策略的处理也是大同小异:
当内存被标记为 Write-Through属性时,读写该内存上的数据,不会被cache缓存,也不会发起cache coherency请求。对于被标记为Write-Through 或者Write-Back的指令数据,它可以被存储在L1 instruction cache,但是只有Write-Back属性的数据可以被缓存到L2 cache或者L3 cache。

同Cortex-A53一样,其CCSIDR的WT状态位也始终为0,说明对Cortex-A55 来讲,它的任何级别的cache(L1/L2/L3)都不支持 Write-Through 策略。
在这里插入图片描述
在这里插入图片描述

这篇关于以ARM Cortex-A55/A53为例分析 L1/L2/L3 cache所支持的写策略(write-back/wirte-through,写通和写回)的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



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

相关文章

SpringBoot中六种批量更新Mysql的方式效率对比分析

《SpringBoot中六种批量更新Mysql的方式效率对比分析》文章比较了MySQL大数据量批量更新的多种方法,指出REPLACEINTO和ONDUPLICATEKEY效率最高但存在数据风险,MyB... 目录效率比较测试结构数据库初始化测试数据批量修改方案第一种 for第二种 case when第三种

解决1093 - You can‘t specify target table报错问题及原因分析

《解决1093-Youcan‘tspecifytargettable报错问题及原因分析》MySQL1093错误因UPDATE/DELETE语句的FROM子句直接引用目标表或嵌套子查询导致,... 目录报js错原因分析具体原因解决办法方法一:使用临时表方法二:使用JOIN方法三:使用EXISTS示例总结报错原

MySQL中的LENGTH()函数用法详解与实例分析

《MySQL中的LENGTH()函数用法详解与实例分析》MySQLLENGTH()函数用于计算字符串的字节长度,区别于CHAR_LENGTH()的字符长度,适用于多字节字符集(如UTF-8)的数据验证... 目录1. LENGTH()函数的基本语法2. LENGTH()函数的返回值2.1 示例1:计算字符串

Android kotlin中 Channel 和 Flow 的区别和选择使用场景分析

《Androidkotlin中Channel和Flow的区别和选择使用场景分析》Kotlin协程中,Flow是冷数据流,按需触发,适合响应式数据处理;Channel是热数据流,持续发送,支持... 目录一、基本概念界定FlowChannel二、核心特性对比数据生产触发条件生产与消费的关系背压处理机制生命周期

怎样通过分析GC日志来定位Java进程的内存问题

《怎样通过分析GC日志来定位Java进程的内存问题》:本文主要介绍怎样通过分析GC日志来定位Java进程的内存问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录一、GC 日志基础配置1. 启用详细 GC 日志2. 不同收集器的日志格式二、关键指标与分析维度1.

MySQL中的表连接原理分析

《MySQL中的表连接原理分析》:本文主要介绍MySQL中的表连接原理分析,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录1、背景2、环境3、表连接原理【1】驱动表和被驱动表【2】内连接【3】外连接【4编程】嵌套循环连接【5】join buffer4、总结1、背景

python中Hash使用场景分析

《python中Hash使用场景分析》Python的hash()函数用于获取对象哈希值,常用于字典和集合,不可变类型可哈希,可变类型不可,常见算法包括除法、乘法、平方取中和随机数哈希,各有优缺点,需根... 目录python中的 Hash除法哈希算法乘法哈希算法平方取中法随机数哈希算法小结在Python中,

SpringBoot中4种数据水平分片策略

《SpringBoot中4种数据水平分片策略》数据水平分片作为一种水平扩展策略,通过将数据分散到多个物理节点上,有效解决了存储容量和性能瓶颈问题,下面小编就来和大家分享4种数据分片策略吧... 目录一、前言二、哈希分片2.1 原理2.2 SpringBoot实现2.3 优缺点分析2.4 适用场景三、范围分片

Java Stream的distinct去重原理分析

《JavaStream的distinct去重原理分析》Javastream中的distinct方法用于去除流中的重复元素,它返回一个包含过滤后唯一元素的新流,该方法会根据元素的hashcode和eq... 目录一、distinct 的基础用法与核心特性二、distinct 的底层实现原理1. 顺序流中的去重

k8s上运行的mysql、mariadb数据库的备份记录(支持x86和arm两种架构)

《k8s上运行的mysql、mariadb数据库的备份记录(支持x86和arm两种架构)》本文记录在K8s上运行的MySQL/MariaDB备份方案,通过工具容器执行mysqldump,结合定时任务实... 目录前言一、获取需要备份的数据库的信息二、备份步骤1.准备工作(X86)1.准备工作(arm)2.手