我在基于 AMD64 的硬件上使用 32 位 RHEL 4.4。 这是 uname -a 的输出
$ uname -a
Linux zulu 2.6.9-42.0.10.ELsmp #1 SMP Fri Feb 16 17:17:21 EST 2007 i686 athlon i386 GNU/Linux
我在这个系统上安装了 8Gigs 内存，操作系统是 32 位，我假设我的系统将无法充分利用 8GB 内存。 但是当我运行 top 时，我看到以下内容 -
Mem: 8309168k total, 8292028k used, 17140k free, 7096k buffers
因此，top 能够查看所有 8GB 内存。
如果我在同一台计算机上安装 32 位 WinXP，任务管理器仅显示 3 GB 可用。
我的问题是 - 32 位操作系统如何能够看到 8GB 内存？ 这是否意味着我的应用程序将能够使用更大的地址空间？ 为什么32位Linux和32位WinXP有区别？
谢谢！
I am using 32 bit RHEL 4.4 on AMD64 based hardware. Here is the output from uname -a
$ uname -a
Linux zulu 2.6.9-42.0.10.ELsmp #1 SMP Fri Feb 16 17:17:21 EST 2007 i686 athlon i386 GNU/Linux
I have 8Gigs of memory installed on this system, OS being 32 bits I would assume that my system will not be able to make use of full 8GB memory. But when I run top, I see the following -
Mem: 8309168k total, 8292028k used, 17140k free, 7096k buffers
So, top is able to view all 8GB of memory.
If I install 32 bit WinXP in same machine, task manager just shows 3 GB as available.
My question is - How is 32 bit OS able to see 8GB memory? Does this mean that my applications will be able to use larger address space? And why is the difference between 32 bit Linux and 32 bit WinXP?
Thanks!
发布评论
评论（4）
您的 Linux 系统支持物理地址扩展。
Your Linux system supports Physical Address Extension.
记忆有不同的“级别”。 无论操作系统如何，在一个进程中寻址超过 4Gb 的内存都是不可能的，因为您的指针太小，无法容纳更多内存 - 这是 32 位内存的基本限制。 在 Linux 和 Windows 以及我猜想的大多数“传统”操作系统上，32 位虚拟地址空间被分为一部分用于内核，一部分用于进程，因此每个进程获得的可寻址内容少于 4 GB。
但操作系统仍然可以使用超过 4 Gb 的内存 - 例如，有 2-3 个进程，每个进程消耗 2 Gb 内存。 即使 32 位 CPU 也可以寻址超过 4 Gb 的内存（在硬件级别），但在虚拟地址空间中，您始终受到 32 位指针的限制。
老新事物对物理地址空间、虚拟地址空间和co之间的区别有很好的解释：http://blogs.msdn.com/oldnewthing/archive/2004/08/18/216492.aspx
There are different 'levels' of memory. What is impossible, whatever the OS, is to address more than 4Gb in one process, since your pointers are too small for more than that - that's the fundamental limitation of 32 bits w.r.t memory. On linux and windows, and most 'traditional' OSs I would guess, the 32 bits virtual address space is split into one part for the kernel and one part for the process, so you get less than 4 Gb of addressable content for each process.
But still, the OS could use more than 4 Gb - for example, having 2-3 processes each consuming 2 Gb of memory. Even 32 bits CPU can address more than 4 Gb of memory (at the hardware level), but in the virtual address space, you are always limited by your 32 bits pointers.
The old new thing has a good explanation on the differences between physical address space, virtual address space and co: http://blogs.msdn.com/oldnewthing/archive/2004/08/18/216492.aspx
实现这一点的方法称为“PAE”（物理地址扩展）。 您的 CPU 能够在内部使用 36 位地址，并且您的操作系统也支持它。 不幸的是，Windows XP 仅使用 PAE 来支持 NX 位（No eXecution 位，当处理器尝试从标有该位的页面执行代码时会导致发生异常）。 32位Linux内核支持PAE。
The method enabling this is called "PAE" (Physical address extension). Your CPU is able to use 36bit addresses internally, and your OS supports it. Unfortunately, Windows XP only uses PAE in order to support the NX bit (No eXecution bit, causes an exception to occur when the processor tries to execute code from a page marked with this bit). 32bit Linux kernels support PAE.
较新的 i386 兼容 CPU 可以使用 PAE 模式寻址超过 4 GB。 Windows XP 人为地将地址空间限制为 4GB，因为有太多编写糟糕的硬件驱动程序假设所有 DMA 都将针对低于 4GB 的内存进行。 因此，4 GB 地址空间中大约 1 GB 映射到硬件，其余映射到物理 RAM。 Windows 服务器版本没有此限制。 支持 PAE 的 Linux 内核也不限制内存。 如果我没记错的话，这两款都支持最大 32GB。
您的应用程序的地址空间被限制在 2-3 GB 之间，具体取决于操作系统选项。 例如，与通过使用地址窗口扩展或内存映射文件将内存部分进出该地址空间的窗口相比，一个应用程序可以有效地使用更多的物理 RAM。
Newer i386-compatible CPUs can address more than 4 GB using PAE mode. Windows XP artificially limits the address space to 4GB because there are too many poorly written hardware drivers that assume all DMA is will be done to memory below 4 GB. So, about 1 GB of the 4 GB address space is mapped to hardware, the rest to physical RAM. Windows server editions don't have this limitation. Linux kernels that support PAE don't limit memory either. Both of these support up to 32GB, if I remember correctly.
Your application is limited to somewhere between 2-3 GB of address space, depending on OS options. One application can effectively use more physical RAM than that by windowing portions of memory in and out of that address space, using address windowing extensions, or memory mapped files, for example.