caching - 内存分页和 CPU 缓存线之间的关系
问题描述
这是我对Paging
and的理解CPU Cache lines
:
Paging
是计算机存储和从硬盘检索数据的内存管理方案。
Paging
与 CPU 加载/存储无关。
Cache line
是内存和 CPU 寄存器之间存储和检索数据的大小。
Cache line
与硬盘加载/存储无关。
我的问题是:
1-我上面提到的理解正确吗?
2-当aPage fault
发生时,操作系统如何知道在硬盘中寻找数据加载的位置?假设我需要0x123
从内存中加载地址,但该地址尚未分页,0x123
数据在磁盘上的什么位置?
解决方案
你所说的大部分内容都不正确。分页部分由 CPU 实现,部分由操作系统实现。
分页与 RAM 有关,主要用于更好的内存管理。
如今,对所谓的(在 Linux 中)交换空间的需求并不多。当操作系统缺少 RAM 空间时,交换空间用于将 RAM 中的页面临时存储在硬盘上。由于 RAM 越来越多地以较低的成本提供。我认为很少会使用交换空间。
至于高速缓存,CPU中有几个高速缓存。众所周知,主缓存具有多个级别,例如 L1、L2 等。它存储的页面有更高的重用机会。它由 CPU 管理,对操作系统不可见。
TLB 是另一个缓存,用于存储虚拟地址到物理地址的转换。使用它是为了每次在代码中访问某个虚拟地址时都不需要重做翻译。它也由 CPU 管理。更改执行进程时必须刷新 TLB。
分页内存管理方案用于管理 RAM 内存而不是硬盘。
在 x86 上,有一个控制寄存器 (CR3),用于存储用于虚拟地址转换的第一个表的地址。一旦通过在其控制寄存器(CR0,CR4)中设置一些标志在处理器中启用分页,它将开始使用内存管理单元(MMU)将您引用的虚拟地址转换为物理地址。在地址总线上输出一个值之前,该值会经过 MMU 进行转换。MMU 将查看 CR3 寄存器引用的地址,该寄存器位于 RAM 中,并在引导或执行期间由操作系统初始化。
例如,对于 x86-64(最现代),分页方案由 intel IA-32e 调用。它有 4 个级别的分页,称为 PLM4、PDPT、PDT 和 PT(参见https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-软件开发者-vol-3a-part-1-manual.pdf)。
在这种分页方案中,虚拟地址将有 64 位,但仅使用 48 位。每 4 个表使用 9 位作为偏移量。最后 12 位(最低有效位)将用作物理页本身的偏移量。
如果你有地址 0x123。这给
0x00 00 00 00 00 00 01 23
或二进制
Not used Offset in pml4 Offset in pdpt Offset in pdt
0000000000000000 000000000 000000000 000000000
Offset in pt Offset in page
000000000 0001 0010 0100
因此,您将引用 pml4 中的条目 0、pdpt 中的 0、pdt 中的 0 和 pt 中的 0。在这些条目引用的页面中,您将有 0x123 的偏移量。
推荐阅读
- r - 创建多个根据现有变量计算的新变量
- javascript - 强制硬重新加载
- c# - ASP.NET Core 中的线程问题
- javascript - Sequelize 迁移错误:无法读取未定义的属性“长度”
- python - 如何正确绘制这组数据
- symfony - 锁定文件不是最新的 composer.json 中的最新更改
- r - dbplyr 中 database.table 的语法?
- angular - Angular 7.0.3 cli - 从 webpack 包动态加载外部模块
- python - Python 中的 Python Repl
- android - Android推送几秒钟后消失