E500 MMU 架构及VxWorks 下的优化

简介: E500 MMU 架构及VxWorks 下的优化

E500 Core 的 MMU/TLB 结构


MMU 是存储器管理单元的缩写,是用来管理虚拟内存系统的器件。MMU通常是CPU的一部分,本身有少量存储空间存放从虚拟地址到物理地址的匹配表,此表称做TLB。MMU的两个主要功能是:

(1)将访问主存和访问I/O的逻辑地址转化为物理地址。

(2)内存保护。根据需要对特定的内存区块的访问进行保护,通过这一功能,可以将特定的内存块设置成只读、只写或是可同时读写


MMU在体系结构中的位置:


微信图片_20230117162601.png


地址映射机制必须使一个程序能断言某个地址在其自己的进程空间或地址空间内,并且能够高效地将其转换为真实的物理地址以访问内存。一个方法是使用一个含有整个空间内所有页的入口(entry)的表(即页表),每个入口包含这个页的正确物理地址。这很明显是个相当大的数据结构,因而不得不存放于主存之中。


由于CPU首先接到的是由程序传来的虚拟内存地址,所以CPU必须先到物理内存中取页表,然后对应程序传来的虚拟页面号,在表里找到对应的物理页面号,最后才能访问实际的物理内存地址,也就是说整个过程中 CPU 必须访问两次物理内存(实际上访问的次数更多)。因此,为了减少CPU访问物理内存的次数,引入TLB。


TLB 和 CPU 里的一级、二级缓存之间不存在本质的区别,只不过前者缓存页表数据,而后两个缓存实际数据。它们和内存区域的对应关系如图所示。


微信图片_20230117162610.png


VxWorks 对 E500 Core MMU 的支持


E500 处理器内核实现了 Book E 处理器规范,MMU 总是处于活动状态,任何内存地址访问内存必须经过TLB0(动态,固定4 KB页大小TLB)或者TLB1(静态,可变页大小TLB)翻译得到物理地址。

VxWorks 嵌入式操作系统很好地支持了 E500 处理器内核的 MMU,其中 BSP(Board Support Pack-age)中的数组 sysStaticTlbDesc[](定义在 sysLib.c)用于配置TLB1的地址映射,这个数组中的每一项可以指定地址空间(TS 位)为 0 或者 1;BSP 中的数组 sysPhyMemDesc[](也定义在 sysLib.c),数组用于配置TLB0 的地址映射,地址空间(TS 位)默认为 1,不可指定。


sysStaticTlbDesc[]数组最多只能配置 16 个 Entry,每个 entry 映射的地址范围是可变的,从 1 kB~256 MB 不等。在 sysStaticTlbDesc[]中首先要保证为VxWorks 启动和基本操作所需的各地址区域具有地址空间0的配置。


sysPhyMemDesc[]数组中的每个元素描述了物理内存中一个连续的块,其中包括物理地址、物理地址映射的虚拟地址(一般情况下与物理地址相同)、该块内存初始化状态信息、掩码信息。其可包含的映射空间有内存、Flash、ROM、I/O 设备等,可以根据系统的需求自行进行配置。在VxWorks的默认配置中,地址空间1下全部系统内存(RAM)都配置在sysPhyMemDesc[]数组中。


Vx Works 下 E500 Core MMU 的优化方法


VxWorks 在默认情况下为地址空间 1 运行所需的系统内存(System RAM)空间全部配置在sysPhysMemDesc[]数组中,即由 TLB0 来管理的。这样会有

下列两个缺点:

(1)会使 TLB0 过大,查询 TLB0 的时间会比较长,每次访问内存的时间就被相应延长,从而影响系统的实时性能。

(2)由于 TLB0 项数的限制(256,E500V1;512,E500V2,在系统内存(RAM)超过 1 GB(1 GB/4 KB=256)或者 2 GB(2 GB/4 KB=512)的情况下,不可能每一页都在 TLB0 中长期驻留,况且 TLB0 中还要配置ROM,外设,寄存器等的地址空间,这样必然会导致经常性 TLB 缺页(TLB Miss)的发生和页的更新置换,从而进一步影响系统性能。对实时性要求很高的嵌入式操作系统来说,如果经常发生 TLB MISS 或者 TLB 查询时间过长,将是不可接受的。


了减少查询时间和更进一步降低TLB缺页发生的几率,在 TLB1 有剩余可用项的情况下,把一部分系统内存配置在 sysStaticTlbDesc[]数组中,即由TLB1 中来管理和映射。这样既可以减少 TLB0 的项数从而降低整个TLB的查询时间,又可以减少TLB 的缺页几率。但是并非所有的系统内存都可以在TLB1中配置,这是因为 VxWorks 操作系统通常对内核代码,应用程序代码、栈数据和关键数据设置内存保护属性(例如:MMU_ATTR_PROT_SUP_READ,MMU_ATTR_PROT_SUP_WRITE[6]等),这样可以对它们提供有效的保护。但是这些属性TLB1不支持,因此内核代码、应用程序代码、栈数据和关键数据所占有的内存必须由 TLB0 管理,即必须配置在 sysPhysMemDesc[]数组中


目录
相关文章
|
1月前
|
缓存 负载均衡 算法
后端架构设计中的优化技巧
【2月更文挑战第9天】 后端架构设计是一个复杂而关键的工作,不仅需要考虑系统的可靠性和扩展性,还需要保证系统的高性能。本文将介绍一些后端架构设计中的优化技巧,包括数据库设计、缓存优化、负载均衡等方面的内容,帮助开发者在设计后端架构时更好地提升系统性能。
59 1
|
11天前
|
机器学习/深度学习 设计模式 人工智能
人工智能和机器学习技术来优化微服务架构
人工智能和机器学习技术来优化微服务架构
22 1
|
14天前
|
存储 Cloud Native 物联网
数据库技术前沿探索:架构、优化与行业实践
一、引言 在信息化和数字化的浪潮中,数据库技术作为企业核心竞争力的关键要素,其重要性不言而喻
|
18天前
|
存储 缓存 前端开发
单页应用(SPA)的架构与优化:深度探索与实践
【6月更文挑战第11天】本文探讨了单页应用(SPA)的架构与优化,包括前后端分离、路由管理和状态管理基础,以及加载性能、路由和状态管理的优化策略。通过合理设计与优化,SPA能提供流畅体验,同时应对加载性能、路由导航和状态管理的挑战。文章旨在帮助读者理解并提升SPA应用的性能和用户体验。
|
4天前
|
NoSQL Java 数据库
优化基于阿里云的微服务架构下的数据库访问性能
在应对大型电商项目中数据库访问性能瓶颈问题时,团队通过阿里云工具分析发现高QPS、慢查询和不合理数据交互是关键。优化措施包括:1) 索引优化,针对慢查询添加或调整索引;2) 开启读写分离,使用RDS读写分离功能和DRDS进行水平拆分;3) 引入Redis缓存热点数据,减少直接数据库访问;4) 服务化数据访问,降低跨服务数据库调用;5) 使用Sentinel进行限流和熔断,保护数据库资源。这些改进显著提升了系统响应速度和用户体验。
|
27天前
|
数据库 微服务 NoSQL
探索微服务架构下的数据库选型与优化策略
在现代软件开发中,微服务架构已成为一种常见的设计范式。而数据库在微服务架构中的选型与优化策略对整个系统的性能和稳定性至关重要。本文将探讨在微服务环境下,如何选择适合的数据库类型以及优化数据库性能的策略。
|
29天前
|
Kubernetes 负载均衡 应用服务中间件
k8s 二进制安装 优化架构之 部署负载均衡,加入master02
k8s 二进制安装 优化架构之 部署负载均衡,加入master02
|
30天前
|
运维 Cloud Native 安全
云原生架构的未来演进:迈向自我优化的基础设施
【5月更文挑战第30天】 随着企业数字化转型的深入,云原生技术正成为推动现代应用开发和运维模式变革的关键力量。本文探讨了云原生架构如何通过不断的技术迭代,实现自我优化的基础设施,以及这一进化对企业IT策略的影响。文章首先回顾了云原生的概念与核心组件,随后分析了当前云平台在自动化、微服务管理、容器化等方面的最新趋势,并预测了未来可能的发展路径,包括AI辅助的运维、无服务器架构的进一步普及以及安全自动化等。最后,文章提出了企业在采纳云原生技术时的策略建议,以促进业务敏捷性和技术创新。
|
1月前
|
监控 负载均衡 Java
【阿里云云原生专栏】微服务架构在阿里云云原生平台上的应用实例与优化策略
【5月更文挑战第20天】本文介绍了在阿里云云原生平台实现微服务架构的步骤,包括基于Spring Cloud的Docker化部署、使用ACK部署微服务,以及优化策略:服务发现与负载均衡(借助Istio)和监控日志管理。通过这种方式,企业能提升应用的可扩展性、可维护性和敏捷性。
219 5
|
1月前
|
缓存 监控 算法
Python性能优化面试:代码级、架构级与系统级优化
【4月更文挑战第19天】本文探讨了Python性能优化面试的重点,包括代码级、架构级和系统级优化。代码级优化涉及时间复杂度、空间复杂度分析,使用内置数据结构和性能分析工具。易错点包括过度优化和滥用全局变量。架构级优化关注异步编程、缓存策略和分布式系统,强调合理利用异步和缓存。系统级优化则涵盖操作系统原理、Python虚拟机优化和服务器调优,需注意监控系统资源和使用编译器加速。面试者应全面理解这些层面,以提高程序性能和面试竞争力。
30 1
Python性能优化面试:代码级、架构级与系统级优化

热门文章

最新文章