为什么我系统是32位的Ubuntu却能用上4G内存?

重复贴和参考价值不大的帖子,版主维护
头像
东方不坏
帖子: 843
注册时间: 2007-04-05 3:09
系统: Deepin
来自: 身后某处
送出感谢: 2 次
接收感谢: 0
联系:

为什么我系统是32位的Ubuntu却能用上4G内存?

#1

帖子 东方不坏 » 2011-04-28 11:17

可以明确地说,我的系统是32位版本的,为什么会这样?

Screenshot-系统监视器.png
[color=#FFFF00]东方不败[/color] 写了:
  • OS:Ubuntu14.10
  • CPU:Athlon II 651K
  • RAM:威刚DDR3 1600 4GX2双通道
  • 主板:GA-A75M-DS2
  • 硬盘:西数64M版 2T
  • 显卡:迅景6790
  • 显示器:LG W2242TP
头像
东方不坏
帖子: 843
注册时间: 2007-04-05 3:09
系统: Deepin
来自: 身后某处
送出感谢: 2 次
接收感谢: 0
联系:

Re: 为什么我系统是32位的Ubuntu却能用上4G内存?

#2

帖子 东方不坏 » 2011-04-28 11:18

其中的PAE 是什么意思?
[color=#FFFF00]东方不败[/color] 写了:
  • OS:Ubuntu14.10
  • CPU:Athlon II 651K
  • RAM:威刚DDR3 1600 4GX2双通道
  • 主板:GA-A75M-DS2
  • 硬盘:西数64M版 2T
  • 显卡:迅景6790
  • 显示器:LG W2242TP
头像
smallapple
论坛版主
帖子: 7867
注册时间: 2009-03-28 15:12
送出感谢: 0
接收感谢: 19 次

Re: 为什么我系统是32位的Ubuntu却能用上4G内存?

#4

帖子 smallapple » 2011-04-28 11:18

pae
头像
东方不坏
帖子: 843
注册时间: 2007-04-05 3:09
系统: Deepin
来自: 身后某处
送出感谢: 2 次
接收感谢: 0
联系:

Re: 为什么我系统是32位的Ubuntu却能用上4G内存?

#6

帖子 东方不坏 » 2011-04-28 11:19

百科里头找到的:


物理地址扩展
  1. 概述
  [1]
  Physical Address Extension(PAE)技术最初是为了弥补32位地址在PC服务器应用上的不足而推出的。我们知道,传统的IA32架构只有32位地址总线,只能让系统容纳不超过4GB的内存,这么大的内存,对于普通的桌面应用应该说是足够用了。可是,对于服务器应用来说,还是显得不足,因为服务器上可能承载了很多同时运行的应用。PAE技术将地址扩展到了36位,这样,系统就能够容纳2^36=64GB的内存。同时,PAE技术的提出,也是为了解决在PSE技术中,大物理页面必须为4MB的限制。通过前面的讨论,我们知道PSE和PSE-36技术虽然满足了部分应用对大内存页面的需要,但是,从4KB到4MB的跳跃显得太大了一些,现有的操作系统和应用对这种大页面的采用势必会导致严重的页面内碎片,从而浪费内存。PAE技术在Pentium Pro以及以后的CPU中实现,AMD公司也在Athlon以及以后的CPU中普及了这一技术。
  2. 实现
  与PSE、PSE-36技术类似,判断一个CPU是否支持PAE,也可以通过CPUID指令的返回值来取得CPU对PAE的支持信息。激活CPU对PAE的支持,可以通过写CR4的PAE使能位(第5位)来实现。
  由于向下兼容的原因,在拥有PAE技术支持的CPU上运行的操作系统以及应用程序被规定继续沿用以前的32位虚拟地址,通过段式转换,仍然得到32位的线性地址。而打开PAE支持的页式管理系统则负责把32位的线性地址映射到64GB物理空间的任何位置。在PAE技术支持下,系统可以拥有两种大小的物理页面:传统的4KB和2MB页面(注意,不是4MB)。同时,采用PAE技术的页式地址转换与传统的IA32方式有了非常大的变化:首先,IA32中的两级页表在PAE中变成了三层,CR3指向的不再是页目录表,而被称为页目录指针表(Page Directory Pointer Table),它其实是个短表,只包含了4个指向页目录表的指针(在Linux的实现里,被称为中间页表PMD,Page Middle Directory),再由该页目录表指向可以选择的页表(也可以直接指向2MB的物理页面)。其次,虽然页目录表和页表仍然是4KB的大小,但是页目录项和页表项(PDE和PTE)从以前的32位变为了64位。同时,页目录表和页表所容纳的页目录项或页表项也从以前的1024个缩水到了512个。
  在新的页目录表项中,如果PS位(第7位)被设置为1,则该页目录项所指向的就是一个2MB的物理页面,否则,它所指向的就是下一级的页表(注意,这与PSE、PSE-36技术是不同的,在前面的讨论中,我们知道如果仅打开PSE,且PS设置为1,则该页目录项指向的是一个4MB的物理页面)。同时,在PAE中的页目录项新增加了一位,被称为NX(No eXecute)位,它跟其他标志位不同,被放在页目录项的高端(第63位)。我们知道,在传统的IA32架构的页目录项(或者页表项中),高20位存储的是它指向的页表或者物理页面的首地址(因为页表或物理页面都是4KB对齐的,寻址时只需要在这20位后面扩充12个0就是物理地址了),页目录项(或者页表项)的低12位则存储的是它指向的页表或者物理页面的属性(包括PS位)。而使用PAE后,页目录项(或者页表项)已经被扩充到了64位,这64位中能够被用来存储物理地址的位现在一共有:64-1(NX位)-12(属性位)=51。也就是说,极端情况下,一个这样的页目录项(或者页表项)能够覆盖的物理内存范围(如果我们不考虑在该物理地址后面填0来进一步扩充的话)为2^51=2 PetaByte!
  采用PAE技术的页式地址映射机制如下图所示:
  



PAE with 4 KiB pages
  



PAE with 2MB pages
  3. 讨论
  应该说,PAE技术的引入,为x86在内存管理方面带来了翻天覆地的变化。可是,这里,我们要反问自己:为什么要翻天覆地?在前面的讨论中,我们知道PSE-36已经可以管理到64GB的内存,只是管理的方法比较矬而已(在4GB以上只能分配4MB的大页面)。
  首先,我们来分析传统的IA32页目录或页表项能否适应地址总线从32位到36位的变化。我们知道,在传统的IA32页目录或页表项中,除了存储物理地址的20位外,本来还剩下了12位。除了存储若干页属性的位,新增的PS位(第7位),以及必须为0的位(第8位)外,只剩下了3个可用位(第9-11位),也就是说该页目录或页表项最多能容纳23个地址位。假设保持4KB的物理页面大小(实际上这个不可能改,因为要向下兼容,也就是说要让32位的操作系统不加改变就可以运行),这样传统的IA32页表最大能够管理的地址空间为:23+12=35,这与要达到的36个地址位的目标正好差了1位!这样,在往36位甚至更高的64位扩展,而又要保证向下兼容性的前提下,传统的IA32页式地址映射机制中页目录或页表项的32位存储空间就显得太小,对它的扩充是必然的。
  可是如果将这些表项的大小进行扩充,一个4KB的物理页面能够容纳的表项的数目必然会变少。将其扩充1倍到64位,那么一个4KB的物理页面只能容纳512个表项,也就是说每一级页表或者页目录能够覆盖的地址位就从以前的10位变到了9位。这样很自然的,32-12-9-9=2,也就是说还剩下2个地址位没有被覆盖,这样就自然地催生了三级页目录、页表结构,而最高的页指针目录就只用覆盖2位,拥有4个表项就够了。
  从另一个角度来看这个问题。我们前面讨论过,PSE和PSE-36技术扩充的大页面只能是4MB,这跟传统的4KB页面相比,显得跳跃太大,会浪费不少空间。而在三级页表结构中,我们正好有了机会来修正这个错误:9+12=21,那么2^21=2MB。所以,采用新的三级页表结构,我们就可以支持2MB的大页面了。那么新的三级页表结构能够比较方便地实现同时支持4MB的大物理页面吗?这个问题留给读者来思考。另一个问题是,如果我们要在三级地址映射的机制上支持4KB和1MB两种页面大小,页式地址映射机制应该如何改变?
  从以上的分析,我们可以看到,三级页表结构虽然是不得已而为之,但确实达到了将地址总线宽度扩展到36位,且同时支持2MB的大物理页面,这两个目的,可谓一箭双雕!所以三级页表结构绝不是Intel的工程师随意为之,而是经过了慎重的思考和利益的权衡的。
  随着PAE技术的引入,如果系统使能了PAE,则传统的IA32页式地址映射机制,以及刚讨论的PSE、PSE-36就都成了历史。同时,PAE技术的引入,将页目录和页表项扩充到了64位,这也为以后的x86-64的地址进一步扩展打下了基础,虽然是无意的。
  Linux内核对PAE的支持始于2.3.23,当然,为了管理更大的地址空间,必须在支持PAE的CPU上运行支持PAE的内核。到了2009年,支持PAE技术的内核已经成了Linux发行版的默认配置。
  最后,需要特别指出的是,虽然PAE技术将系统实际的物理寻址空间扩展到了36位,然而,对于操作系统和应用程序来说,它们能够使用的逻辑地址仍然是32位的!也就是说,应用能够用到的逻辑内存只有4GB(当然还要减去操作系统所占的逻辑地址空间)。这要到x86-64技术推出后,情况才得以改观。
[color=#FFFF00]东方不败[/color] 写了:
  • OS:Ubuntu14.10
  • CPU:Athlon II 651K
  • RAM:威刚DDR3 1600 4GX2双通道
  • 主板:GA-A75M-DS2
  • 硬盘:西数64M版 2T
  • 显卡:迅景6790
  • 显示器:LG W2242TP
头像
eexpress
帖子: 58428
注册时间: 2005-08-14 21:55
来自: 长沙
送出感谢: 4 次
接收感谢: 256 次

Re: 为什么我系统是32位的Ubuntu却能用上4G内存?

#7

帖子 eexpress » 2011-04-28 11:20

谁告诉你安装pae的。老实说。
:em04
● 鸣学
levee
帖子: 3030
注册时间: 2009-10-03 23:31
送出感谢: 0
接收感谢: 13 次

Re: 为什么我系统是32位的Ubuntu却能用上4G内存?

#8

帖子 levee » 2011-04-28 11:24

大内存还是直接上64位的吧。
jtshs256
论坛版主
帖子: 22323
注册时间: 2010-07-19 21:41
系统: OS X
送出感谢: 2 次
接收感谢: 27 次

Re: 为什么我系统是32位的Ubuntu却能用上4G内存?

#9

帖子 jtshs256 » 2011-04-28 11:25

u安装时自动判断的…
NO DO NO DIE
http://a/%%30%30
头像
东方不坏
帖子: 843
注册时间: 2007-04-05 3:09
系统: Deepin
来自: 身后某处
送出感谢: 2 次
接收感谢: 0
联系:

Re: 为什么我系统是32位的Ubuntu却能用上4G内存?

#10

帖子 东方不坏 » 2011-04-28 11:27

eexpress 写了:谁告诉你安装pae的。老实说。
:em04

我也不记得了,真的。
[color=#FFFF00]东方不败[/color] 写了:
  • OS:Ubuntu14.10
  • CPU:Athlon II 651K
  • RAM:威刚DDR3 1600 4GX2双通道
  • 主板:GA-A75M-DS2
  • 硬盘:西数64M版 2T
  • 显卡:迅景6790
  • 显示器:LG W2242TP
头像
东方不坏
帖子: 843
注册时间: 2007-04-05 3:09
系统: Deepin
来自: 身后某处
送出感谢: 2 次
接收感谢: 0
联系:

Re: 为什么我系统是32位的Ubuntu却能用上4G内存?

#11

帖子 东方不坏 » 2011-04-28 11:27

jtshs256 写了:u安装时自动判断的…

我用光盘装的10.10,然后升级成11.4
[color=#FFFF00]东方不败[/color] 写了:
  • OS:Ubuntu14.10
  • CPU:Athlon II 651K
  • RAM:威刚DDR3 1600 4GX2双通道
  • 主板:GA-A75M-DS2
  • 硬盘:西数64M版 2T
  • 显卡:迅景6790
  • 显示器:LG W2242TP
头像
zkwlx
帖子: 989
注册时间: 2009-10-09 12:54
系统: debian
来自: 北京某胡同
送出感谢: 3 次
接收感谢: 2 次

Re: 为什么我系统是32位的Ubuntu却能用上4G内存?

#12

帖子 zkwlx » 2011-04-28 11:30

东方不坏 写了:
jtshs256 写了:u安装时自动判断的…

我用光盘装的10.10,然后升级成11.4
着啥急升啊,今天不就正式版了吗 :em04
头像
oneleaf
论坛管理员
帖子: 10208
注册时间: 2005-03-27 0:06
系统: Ubuntu 12.04
送出感谢: 7 次
接收感谢: 99 次

Re: 为什么我系统是32位的Ubuntu却能用上4G内存?

#13

帖子 oneleaf » 2011-04-28 11:32

有一个来自邮件列表的非常古老(2001年)的讨论可以解释下细节:
From: Albert D. Cahalan
Subject: Re: What is the truth about Linux 2.4's RAM limitations?

> RAM)but we had problems with process dying right around 2.3GB (according
> to top).

Out of 3 GB, you had 2.3 GB used and 0.7 GB of tiny chunks of
memory that were smaller than what you tried to allocate.

> * What is the maximum amount of RAM that a *single* process can address
> under a 2.4 kernel, with PAE enabled? Without?

Just the same: 3 GB.

> * And, what (if any) paramaters can effect this (recompiling the app
> etc)?

There is a kernel patch that will get you to 2.0 or 3.5 GB.
The limit is 4 GB minus a power of two big enough for the kernel.

> Linux 2.4 does support greater then 4GB of RAM with these caveats ...
>
> * It does this by supporting Intel's PAE (Physical Address Extension)
> features which are in all Pentium Pro and newer CPU's.
> * The PAE extensions allow up to a maximum of 64GB of RAM that the OS
> (not a process) can address.
> * It does this via indirect pointers to the higher memory locations, so
> there is a CPU and RAM hit for using this.

Sort of. It maps and unmaps memory to access it. You suffer this
with the 4 GB option as well.

> * Benchmarks seem to indicated around 3-6% CPU hit just for using the PAE
> extensions (ie. it applies regardless of whether you are actually
> accessing memory locations greater then 4GB).
> * If the kernel is compiled to use PAE, Linux will not boot on a computer
> whose hardware doesn't support PAE.
> * PAE does not increase Linux's ability for *single* processes to see
> greater then 3GB of RAM (see

I think you mean "Without".

The 4 GB limit is really less, depending on your hardware and BIOS.
Your BIOS will create a memory hole below 4 GB large enough for all
your PCI devices. This hole might be 1 or 2 GB.

> * With 2.4 kernels (with a large memory configuration) a single process
> can address up to the total amount of RAM in the machine minus 1GB
> (reserved for the kernel), to a maximum 3GB.
> * By default the kernel reserves 1GB for it's own use, however I think
> that this is a tunable parameter so if we have 4GB of RAM in a box we
> can tune it so that most of that should be available to the processes
> (?).

Yes. Then you suffer more map/unmap overhead.
From: Jonathan Lundell
Subject: Re: What is the truth about Linux 2.4's RAM limitations?

At 1:01 PM -0700 2001-07-09, Adam Shand wrote:
>So what are the limits without using PAE? Here I'm still having a little
>problem finding definitive answers but ...
>
> * With PAE compiled into the kernel the OS can address a maximum of 4GB
> of RAM.

Do you mean "Without..."?

> * With 2.4 kernels (with a large memory configuration) a single process
> can address up to the total amount of RAM in the machine minus 1GB
> (reserved for the kernel), to a maximum 3GB.
> * By default the kernel reserves 1GB for it's own use, however I think
> that this is a tunable parameter so if we have 4GB of RAM in a box we
> can tune it so that most of that should be available to the processes
> (?).

include/asm-i386/page.h has the key to this partitioning:

/*
* This handles the memory map.. We could make this a config
* option, but too many people screw it up, and too few need
* it.
*
* A __PAGE_OFFSET of 0xC0000000 means that the kernel has
* a virtual address space of one gigabyte, which limits the
* amount of physical memory you can use to about 950MB.
*
* If you want more physical memory than this then see the CONFIG_HIGHMEM4G
* and CONFIG_HIGHMEM64G options in the kernel configuration.
*/

#define __PAGE_OFFSET (0xC0000000)

Whether you could simply bump __PAGE_OFFSET up to (say) 0xE0000000
and get 3.5GB of user-addressable memory I have no idea, but this is
where you'd have to start.

Also keep in mind the distinction between virtual and physical
addresses. A process has virtual addresses that must fit into 32
bits, so 4GB is the most that can be addressed without remapping part
of virtual space to some other physical space.

Also of interest is Chapter 3 of "IA-32 Intel Architecture Software
Developer's Manual Volume 3: System Programming Guide", which you can
find at http://developer.intel.com/design/PentiumIII/manuals/

Keep in mind that Linux uses the flat (unsegmented) model.

PAE extends physical addresses only (to 36 bits), and does nothing
for virtual space.
From: Andi Kleen
Subject: Re: What is the truth about Linux 2.4's RAM limitations?

> * And, what (if any) paramaters can effect this (recompiling the app
> etc)?

The kernel parameter is a constant called __PAGE_OFFSET which you can
set. You also need to edit arch/i386/vmlinux.lds

The reason why your simulation stopped at 2.3GB is likely that the malloc
allocation hit the shared libraries (check with /proc/<pid>/maps). Ways
around that are telling malloc to use mmap more aggressively (see the
malloc documentation in info libc) or moving the shared libraries up
by changing a kernel constant called TASK_UNMAPPED_BASE.
头像
东方不坏
帖子: 843
注册时间: 2007-04-05 3:09
系统: Deepin
来自: 身后某处
送出感谢: 2 次
接收感谢: 0
联系:

Re: 为什么我系统是32位的Ubuntu却能用上4G内存?

#14

帖子 东方不坏 » 2011-04-28 11:37

oneleaf 写了:有一个来自邮件列表的非常古老(2001年)的讨论可以解释下细节:
From: Albert D. Cahalan
Subject: Re: What is the truth about Linux 2.4's RAM limitations?

> RAM)but we had problems with process dying right around 2.3GB (according
> to top).

Out of 3 GB, you had 2.3 GB used and 0.7 GB of tiny chunks of
memory that were smaller than what you tried to allocate.

> * What is the maximum amount of RAM that a *single* process can address
> under a 2.4 kernel, with PAE enabled? Without?

Just the same: 3 GB.

> * And, what (if any) paramaters can effect this (recompiling the app
> etc)?

There is a kernel patch that will get you to 2.0 or 3.5 GB.
The limit is 4 GB minus a power of two big enough for the kernel.

> Linux 2.4 does support greater then 4GB of RAM with these caveats ...
>
> * It does this by supporting Intel's PAE (Physical Address Extension)
> features which are in all Pentium Pro and newer CPU's.
> * The PAE extensions allow up to a maximum of 64GB of RAM that the OS
> (not a process) can address.
> * It does this via indirect pointers to the higher memory locations, so
> there is a CPU and RAM hit for using this.

Sort of. It maps and unmaps memory to access it. You suffer this
with the 4 GB option as well.

> * Benchmarks seem to indicated around 3-6% CPU hit just for using the PAE
> extensions (ie. it applies regardless of whether you are actually
> accessing memory locations greater then 4GB).
> * If the kernel is compiled to use PAE, Linux will not boot on a computer
> whose hardware doesn't support PAE.
> * PAE does not increase Linux's ability for *single* processes to see
> greater then 3GB of RAM (see

I think you mean "Without".

The 4 GB limit is really less, depending on your hardware and BIOS.
Your BIOS will create a memory hole below 4 GB large enough for all
your PCI devices. This hole might be 1 or 2 GB.

> * With 2.4 kernels (with a large memory configuration) a single process
> can address up to the total amount of RAM in the machine minus 1GB
> (reserved for the kernel), to a maximum 3GB.
> * By default the kernel reserves 1GB for it's own use, however I think
> that this is a tunable parameter so if we have 4GB of RAM in a box we
> can tune it so that most of that should be available to the processes
> (?).

Yes. Then you suffer more map/unmap overhead.
From: Jonathan Lundell
Subject: Re: What is the truth about Linux 2.4's RAM limitations?

At 1:01 PM -0700 2001-07-09, Adam Shand wrote:
>So what are the limits without using PAE? Here I'm still having a little
>problem finding definitive answers but ...
>
> * With PAE compiled into the kernel the OS can address a maximum of 4GB
> of RAM.

Do you mean "Without..."?

> * With 2.4 kernels (with a large memory configuration) a single process
> can address up to the total amount of RAM in the machine minus 1GB
> (reserved for the kernel), to a maximum 3GB.
> * By default the kernel reserves 1GB for it's own use, however I think
> that this is a tunable parameter so if we have 4GB of RAM in a box we
> can tune it so that most of that should be available to the processes
> (?).

include/asm-i386/page.h has the key to this partitioning:

/*
* This handles the memory map.. We could make this a config
* option, but too many people screw it up, and too few need
* it.
*
* A __PAGE_OFFSET of 0xC0000000 means that the kernel has
* a virtual address space of one gigabyte, which limits the
* amount of physical memory you can use to about 950MB.
*
* If you want more physical memory than this then see the CONFIG_HIGHMEM4G
* and CONFIG_HIGHMEM64G options in the kernel configuration.
*/

#define __PAGE_OFFSET (0xC0000000)

Whether you could simply bump __PAGE_OFFSET up to (say) 0xE0000000
and get 3.5GB of user-addressable memory I have no idea, but this is
where you'd have to start.

Also keep in mind the distinction between virtual and physical
addresses. A process has virtual addresses that must fit into 32
bits, so 4GB is the most that can be addressed without remapping part
of virtual space to some other physical space.

Also of interest is Chapter 3 of "IA-32 Intel Architecture Software
Developer's Manual Volume 3: System Programming Guide", which you can
find at http://developer.intel.com/design/PentiumIII/manuals/

Keep in mind that Linux uses the flat (unsegmented) model.

PAE extends physical addresses only (to 36 bits), and does nothing
for virtual space.
From: Andi Kleen
Subject: Re: What is the truth about Linux 2.4's RAM limitations?

> * And, what (if any) paramaters can effect this (recompiling the app
> etc)?

The kernel parameter is a constant called __PAGE_OFFSET which you can
set. You also need to edit arch/i386/vmlinux.lds

The reason why your simulation stopped at 2.3GB is likely that the malloc
allocation hit the shared libraries (check with /proc/<pid>/maps). Ways
around that are telling malloc to use mmap more aggressively (see the
malloc documentation in info libc) or moving the shared libraries up
by changing a kernel constant called TASK_UNMAPPED_BASE.


非常谢谢,费了好大的cx劲才看完。
[color=#FFFF00]东方不败[/color] 写了:
  • OS:Ubuntu14.10
  • CPU:Athlon II 651K
  • RAM:威刚DDR3 1600 4GX2双通道
  • 主板:GA-A75M-DS2
  • 硬盘:西数64M版 2T
  • 显卡:迅景6790
  • 显示器:LG W2242TP
头像
oneleaf
论坛管理员
帖子: 10208
注册时间: 2005-03-27 0:06
系统: Ubuntu 12.04
送出感谢: 7 次
接收感谢: 99 次

Re: 为什么我系统是32位的Ubuntu却能用上4G内存?

#15

帖子 oneleaf » 2011-04-28 11:40

具体也可以参考如下地址:

http://kerneltrap.org/node/2450/7217
回复

回到 “归档贴”