操作系统-进程地址空间_进程地址空间
时间：2018-07-19 19:23:21 来源：天一资源网 本文已影响 人 
进程地址空间可以让每个进程都有属于自己独立的虚拟地址空间，其可以通过操作系统映射到物理内存。从用户的角度看，地址空间是一个平坦的线性地址空间，但从内核的角度来看却有所不同。整个进程虚拟地址空间分为两个部分：独立的用户空间和共享的内核空间。针对不同的平台（X86、X86_64），空间的大小有所不同。下边分别针对这两种不同平台的进程地址空间进行相应的介绍。
32位地址空间
线性空间在32位平台上为4GB（2^32）的固定大小，也就是Linux的虚拟地址空间也这么大。Linux内核将这4G字节的空间分为两部分。最高的1G字节（从虚地址0xC0000000到0xFFFFFFFF）供内核使用，称为“内核空间”。而较低的3G字节（从虚地址0x00000000到0xBFFFFFFF），供各个进程使用，称为“用户空间”。因为每个进程可以通过系统调用进入内核，因此,Linux内核空间由系统内的所有进程共享。于是，从具体进程的角度来看，每个进程可以拥有4G字节的虚拟地址空间(也叫虚拟内存)。下图给出了进程虚拟地址空间示意图。
从图中可以看出，每个进程有各自的私有用户空间（0～3G），这个空间对系统中的其他进程是不可见的。最高的1GB内核空间则为所有进程以及内核所共享。另外，进程的“用户空间”也叫“地址空间”。大家都知道Linux内核把物理内存分成3个区：
ZONE_DMA：0~16M
ZONE_NORMAL：16~896M
ZONE_HIGHMEM：高于896M的区域
32位体系架构CPU由于寻址空间只有4G，进程虚拟地址空间也是4G，将高1G（3G~4G）作为内核空间，内核将其中的前两个区也就是前896M与物理内存的0~896M进行直接映射，将剩余128M的虚拟空间作为访问物理内存高于896M的一个转换窗口，这也就是引入高端内存的主要原因，因为32bit的内核1G虚拟地址空间无法建立一个完全的直接映射到整个物理内存空间。对于64bit架构时就不会存在这个问题，可以继续往下看解释。
64bit地址空间
类比于32位平台，很多人就以为在64位平台Linux的虚拟地址空间实际也就是用了2^64字节大小（16EB），这是多么大的一个空间啊！难道真的是这样的吗？下边我们就需要找出依据对其进行断定。
目前根据Intel和AMD架构手册可知r如下，
Intel® 64 and IA-32 Architectures Software Developer Manuals
表中4-level即代表64bit
AMD64 Architecture Programmer’s Manual Volume 2：System Programming
Currently, the AMD64 architecture defines a mechanism for translating 48-bit virtual addresses to 52-bit physical addresses. The mechanism used to translate a full 64-bit virtual address is reserved and will be described in a future AMD64 architectural specification.
无论是Intel还是AMD其64位体系架构都是类似的，64位的虚拟地址空间中只使用了前48位，也就是着64位平台进程的虚拟地址空间大小为2^48=256T,其中规定48：63bit只能是全0或者全1，最低的128T为用户进程空间，从0x00000000 00000000 到 0x00007FFF FFFFFFFF；剩下的为内核空间，从0xFFFF8000 00000000 到 0xFFFFFFFF FFFFFFFF，供所有进程共享。
对于物理内存空间大小允许最大宽度为52bit（也就是64bit操作系统最大支持4PB大小物理内存），实际不同的CPU支持的物理内存宽度也有所不同。目前AMD64架构支持40bit地址大小。整体如下图所示：
对于Linux操作系统内核源码中有对X86_64的线性地址空间布局（Documentation/x86/x86_64/mm.txt）情况，如下整个进程虚拟地址空间框图如下所示，在内核空间中存在一些空洞：
0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm
hole caused by [48:63] sign extension
ffff800000000000 - ffff80ffffffffff (=40 bits) guard hole
ffff880000000000 - ffffc7ffffffffff (=64 TB) direct mapping of all phys. memory
ffffc80000000000 - ffffc8ffffffffff (=40 bits) hole
ffffc90000000000 - ffffe8ffffffffff (=45 bits) vmalloc/ioremap space
ffffe90000000000 - ffffe9ffffffffff (=40 bits) hole
ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB)
... unused hole ...
ffffffff80000000 - ffffffffa0000000 (=512 MB) kernel text mapping, from phys 0
ffffffffa0000000 - ffffffffff5fffff (=1525 MB) module mapping space
ffffffffff600000 - ffffffffffdfffff (=8 MB) vsyscalls
ffffffffffe00000 - ffffffffffffffff (=2 MB) unused hole
整个进程虚拟地址空间框图如下所示，在内核空间中存在一些空洞：
进程用户空间和内核空间对等分，分别占用128T空间，但是在内核空间中还存在一些由于sign extension引起的空洞（此处不太明白为什么会引起空洞），跨过第一个空洞也就是ffff880000000000 - ffffc7ffffffffff 的64T的空间为直接映射物理内存的区域，也就是PAGE_OFFSET为 ffff880000000000 ，这个也是可以从内核源码中有所体现的。在arch/x86/include/asm/Page_types.h文件中对PAGE_OFFSET有如下定义：
#define PAGE_OFFSET ((unsigned long)__PAGE_OFFSET)
继续追踪查看__PAGE_OFFSET，其定义在arch/x86/include/asm/Page_64_types.h中：
#define __PAGE_OFFSET _AC(0xffff880000000000, UL)
熟悉物理内存管理区的都知道x86系统时，高端内存ZONE_HIGHMEM主要作用是由于内核空间只有1G，为了使得内核空间可以使用大于896M的物理内存而存在， 而对于64bit系统，由于直接映射区域就高达64T且很少有物理内存达到64T，所以对于64bit操作系统ZONE_HIGHMEM不再需要。
讲完了64bit系统的进程虚拟地址空间，下边再对物理空间说明下，上边指出物理内存宽度允许的最大宽度为52位，那么实际的CPU物理内存大小是多少呢，如何查看？此处以我的Ubuntu14.04系统来说，可以使用cpuid命令进行查询，如下：
~@ttt-desktop:~$ cpuid | grep 'maximum physical address bits'
maximum physical address bits = 0x24 (36)
maximum physical address bits = 0x24 (36)
可以看出我的Pentium(R) Dual-Core CPU支持的最大物理地址是36位。
