内存寻址答案

【问题标题】：Memory Addressing内存寻址
【发布时间】：2011-03-12 22:04:56
【问题描述】：

我正在阅读http://duartes.org/gustavo/blog/post/motherboard-chipsets-memory-map，具体来说，是以下部分：

在主板中，CPU 的网关到世界是前端的公共汽车连接到北桥。每当 CPU 需要读取或它通过这条总线写内存。它使用一些引脚来传输它想要的物理内存地址写或读，而其他引脚发送要写入或接收的值正在读取的值。英特尔酷睿 2 QX6600有33个引脚传输物理内存地址（所以有 2^33 个内存位置选择）和 64针发送或接收数据（所以数据以 64 位数据传输路径或 8 字节块）。这允许 CPU 物理寻址 64 千兆字节的内存（2^33 个位置 * 8 字节）虽然大多数芯片组只处理多达 8 GB 的 RAM。

现在上面的数学表明，由于有 33 个用于寻址的引脚，2^33 * 8 字节 = 64 GB。一切都很好，但现在我有点困惑。假设我安装了 64 位操作系统，我将能够解决总共 64 GB 或 2^64Gb * 8 = 2^64GB（更多）？另外，假设我在 32 位 cpu 上使用上述相同的 cpu，我仍然只能寻址 4 GB（2^32 位 = 4Gb * 8 = 4GB）？

我认为物理与“允许的操作系统”让我感到困惑。

谢谢！

【问题讨论】：

这个计算没有 OP 错误：2^33 * 8 bytes = 64 GB。我的意思是，有 33 个可寻址引脚，最小可寻址单元是一个字节。因此，2^33 = 8GB 内存。乘法因子 8 是从哪里来的？
@claws: OP 没有错，因为实际上有 36 个地址行（=> 2^36 = 64GB;）但只能使用 [0-32] 行（即 33 行）把地址。由于 DataBus 是 64 位（= 8 字节），因此它会获取所有 8 个字节，这些字节可以用放置在这 33 个（共 36 个）行上的地址构成。

标签： memory memory-management 64-bit

【解决方案1】：

你混淆了一堆东西：

指针的大小限制了用户进程可以访问的虚拟内存量。并非所有这些实际上都可供您的进程使用（传统上保留“高”1 或 2 GB 供内核使用）。
并非所有虚拟地址位都有效。最初的 AMD64 实现有效地使用了 48 位符号扩展地址（即 [0x0000800000000000,0xFFFF7FFFFFFFFFFF] 范围内的地址无效）。这主要是为了将页表限制为 4 级，从而降低页面错误的成本；假设 4K 页，您需要 6 级页表来处理完整的 2^64 位。作为比较，i386 有 2 级页表。
并非所有虚拟地址在任何给定时间都需要与物理地址相对应。这就是虚拟内存的重点：您可以寻址“物理上”不存在的内存，然后操作系统会为您分页。
并非所有物理地址都对应于虚拟地址。一方面，它们可能没有被映射，但也有可能拥有比您可以处理的更多的物理内存。 PAE 支持高达 64 GB 的物理地址，并且在 AMD64 之前的服务器上很常见。虽然单个进程无法处理 64 GB，但这意味着您可以运行大量数 GB 的进程而无需一直进行交换。
最后：物理地址超出 RAM 插槽的处理能力是没有意义的。我有一块支持 AMD64 的 D945GCLF2 板，但只有 2 GB 的 RAM。无论如何都不能使用额外的物理地址线是没有意义的。（我正在讨论内存映射设备和时髦的两个 DIMM 一个插槽的东西，我忘记了它的名字。）

另外，请注意其他一些事项：

对于内存映射 I/O（在硬件意义上），CPU 需要寻址单个字节。它不能只进行 64 位访问。这似乎被掩盖了。
现代处理器在 CPU 上包含内存控制器，而不是使用传统的北桥和 FSB（请参阅 HyperTransport 和 QuickPath）。

【讨论】：

【解决方案2】：

是的，物理地址和虚拟地址中的位数可以不同。说，这里是 64 位 Linux 关于内核的说法 (cat /proc/cpuinfo)：

...
processor       : 3
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 33
model name      : Dual Core AMD Opteron(tm) Processor 280
stepping        : 2
cpu MHz         : 2392.623
cache size      : 1024 KB
...
bogomips        : 4784.41
TLB size        : 1088 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp

【讨论】：

【解决方案3】：

关于物理地址线有几点需要考虑：

每条物理地址线（“引脚”）都引用一个前端总线字，而不是字节地址。如果 CPU 获取 64 位字，则物理地址线将与该 8 字节边界对齐。因此，地址线 A0-A2 不连线，因为它们总是为零。因此，物理线路的字节地址范围增加了前端总线的宽度。
虚拟内存系统可以维护 64 位虚拟地址到 n 位物理地址的映射。实际上，操作系统会维护一个虚拟机映射不超过的“物理最大地址”值。
某些内存架构允许内存库分页，其中 CPU 外硬件通过为不同的内存“库”重新使用一些物理地址来增加有效的物理内存地址范围。

【讨论】：

【解决方案4】：

想象一下，在 64 位操作系统中，一些用于寻址内存的线路无法连接到任何地方。操作系统知道这很令人困惑，因此它采用标准的 64 位地址并使用虚拟内存映射来让您相信您生活在一个平坦的 64 位空间中。

【讨论】：

【解决方案5】：

芯片组限制是一个很大的因素——主板上的硬件必须能够将地址从 CPU 传递到 RAM。因此，除非您的主板设计用于处理更多容量，否则 8GB 限制将适用。

作为参考，当前的 64 位 CPU 将地址空间的高 x 位数（介于 8 和 24 位之间）连接在一起，因为 64 位现在只是太多的地址空间（你会需要 80 亿个 2GB 模块来占用那么多地址空间）。例如，AMD 对单个段中的地址空间有 48 位限制 (IIRC)。这绰绰有余，但远不及理论最大值。

【讨论】：

【解决方案6】：

64 位和 32 位操作系统之间的主要区别在于，人们只是将原始数据类型（例如单词）视为更广泛。如果 CPU 只能物理寻址 2^33 个位置，那不会因为您使用的是 64 位操作系统而改变。另一方面，使用 32 位操作系统通常会限制您的可寻址内存，因为 32 位指针不能代表您的 CPU 可用于寻址内存的所有可能值（在您的示例中，32 位指针是一个有点短）。

长话短说，您的可寻址内存受到指针宽度（操作系统限制）和数据地址总线宽度（物理限制）的限制。一些架构有巧妙的方法通过使用两个指针来绕过操作系统指针宽度，一个用于寻址内存“银行”，另一个用于在银行内进行本地寻址。不过，这些方案最近有点过时了。

此外，现代操作系统通常使用虚拟内存子系统，将逻辑地址转换为相应的物理地址。使用缓存，内存的实际物理位置可能位于内存层次结构中的一个（或多个！）组件中（例如处理器缓存、主内存、硬盘等）。不知道我是如何完全忘记提及 VM 的，但它肯定会帮助您了解调查它。

【讨论】：

【解决方案7】：

我相信，如果你有一个 64 位操作系统，你可以（理论上）寻址 2^64 * 8 字节 = 16 EB（艾字节），但你会受到硬件限制为 2^33 * 8 字节 = 64国标。如果您有 32 位操作系统，您将无法利用全部硬件容量，因为操作系统是限制因素，只能表示 2^32 个不同的地址。我可能会离开，但这是我目前的理解。

【讨论】：

从未如此简单。 PAE 和 PSE-36 都为您提供 32 位机器上的 36 位硬件寻址。
你有点离题了。 32 位 x86 操作系统可以使用 PAE 处理高达 64GB 的内存。

【解决方案8】：

我认为您对内存同时存储 8 个字节的事实感到困惑，但地址（在 CPU 级别）指的是 1 个字节（而不是一堆 8 个字节）。因此，使用 32 位，您可以“参考”2^32 字节 = 4GB。如果您更喜欢指针上的 +8 对应于“物理”行号上的 +1。然后，您可以使用分页访问更多内存（不确定它是否仍在现代计算机中使用）。

以图书馆为例，您（或 CPU）可以枚举 32^2 本书，但图书馆员（芯片组）处理书架。所以第 10 本书适合你，是第 2 本书或第 2 书架，但你永远看不到书架编号。图书馆员的工作就是去好书架上给你带来好书。对我来说（同一台计算机上的另一个程序）书 #10 可能是不同的书：书架 100002 的书 #2（因为我的页面从书架 10000 开始）我们都可以参考 32^2 种不同的书，但它们并不相同（图书馆可以拥有更多）。

（自从我学习计算机以来，变化发生了很大变化，所以我所说的可能不是100％准确，但我认为这个想法是存在的）

【讨论】：