转自:http://www.cnblogs.com/zhaoyl/p/3695517.html
1、虚拟地址、线性地址、逻辑地址、物理地址
虚拟地址又叫线性地址。由于Linux没有采用分段机制(不确定是没有采用分段机制,还是采用的是最低限制的分段机制),所以逻辑地址和虚拟地址(也就是线性地址)是一个概念。内核的虚拟地址和物理地址大部分只差一个线性偏移量;而用户空间的虚拟地址和物理地址则采用了多级页表进行映射,但仍称之为线性地址。
2、DMA/HIGH_MEM/NORMAL分区
在x86结构中,
Linux内核虚拟地址空间划分0~3G为用户空间,3~4G为内核空间(注意,内核可以使用的线性地址只有1G。内核虚拟空间(3G~4G)又划分为三种类型的区:
ZONE_DMA 3G之后起始的16MB
ZONE_NORMAL 16MB~896MB
ZONE_HIGHMEM 896MB ~1G
ZONE_DMA 3G之后起始的16MB
ZONE_NORMAL 16MB~896MB
ZONE_HIGHMEM 896MB ~1G
由于
内核的虚拟地址和物理地址只差一个偏移量:
物理地址 = 逻辑地址 – 0xC0000000。所以如果1G内核空间完全用来线性映射,显然物理内存也只能访问到1G区间,这显然是不合理的。HIGHMEM就是为了解决这个问题,专门开辟的一块不必线性映射,可以灵活定制映射,以便访问1G以上物理内存的区域。从网上扣来一图,如下:
、
高端内存的划分,又如下图:
内核直接映射空间 PAGE_OFFSET~VMALLOC_START,kmalloc和__get_free_page()分配的是这里的页面。二者是借助slab分配器,直接分配物理页再转换为逻辑地址(物理地址连续)。适合分配小段内存。此区域 包含了内核镜像、物理页框表mem_map等资源。
内核动态映射空间 VMALLOC_START~VMALLOC_END,被vmalloc用到,可表示的空间大。
内核永久映射空间 PKMAP_BASE ~ FIXADDR_START,kmap
内核临时映射空间 FIXADDR_START~FIXADDR_TOP,kmap_atomic
关于页面分配采用的伙伴算法和slab分配器,请自行查询。
3、内存映射
内存映射分为文件映射和匿名映射。
文件映射是指代表这个映射的vma对应到一个文件中的某个区域。这种映射方式相对较少被用户态程序显式地使用,用户态程序一般习惯于open一个文件、然后read/write去读写文件。而实际上,用户程序也可以使用mmap系统调用将一个文件的某个部分映射到内存上(对应到一个vma),然后以访存的方式去读写文件。尽管用户程序较少这样使用,但是用户进程中却充斥着这样的映射:进程正在执行的可执行代码(包括可执行文件、lib库文件)就是以这样的方式被映射的。
在《 linux内核文件读写浅析》一文中,我们并没有讨论关于文件映射的实现。实际上,文件映射是将文件的磁盘高速缓存中的页面直接映射到了用户空间(可见,文件映射的页面是磁盘高速缓存页面的子集),用户可以0拷贝地对其进行读写。而使用read/write的话,则会在用户空间的内存和磁盘高速缓存间发生一次拷贝。
匿名映射相对于文件映射,代表这个映射的vma没有对应到文件。对于用户空间普通的内存分配(堆空间、栈空间),都属于匿名映射。
显然,多个进程可能通过各自的文件映射来映射到同一个文件上(比如大多数进程都映射了libc库的so文件);那匿名映射呢?实际上,多个进程也可能通过各自的匿名映射来映射到同一段物理内存上,这种情况是由于fork之后父子进程共享原来的物理内存(copy-on-write)而引起的。
文件映射又分为共享映射和私有映射。私有映射时,如果进程对映射的地址空间进行写操作,则映射对应的磁盘高速缓存并不会直接被写。而是将原有内容复制一份,然后再写这个复制品,并且当前进程的对应页面映射将切换到这个复制品上去(写时复制)。也就是说,写操作是只有自己可见的。而对于共享映射,写操作则会影响到磁盘高速缓存,是大家都可见的。
文件映射是指代表这个映射的vma对应到一个文件中的某个区域。这种映射方式相对较少被用户态程序显式地使用,用户态程序一般习惯于open一个文件、然后read/write去读写文件。而实际上,用户程序也可以使用mmap系统调用将一个文件的某个部分映射到内存上(对应到一个vma),然后以访存的方式去读写文件。尽管用户程序较少这样使用,但是用户进程中却充斥着这样的映射:进程正在执行的可执行代码(包括可执行文件、lib库文件)就是以这样的方式被映射的。
在《 linux内核文件读写浅析》一文中,我们并没有讨论关于文件映射的实现。实际上,文件映射是将文件的磁盘高速缓存中的页面直接映射到了用户空间(可见,文件映射的页面是磁盘高速缓存页面的子集),用户可以0拷贝地对其进行读写。而使用read/write的话,则会在用户空间的内存和磁盘高速缓存间发生一次拷贝。
匿名映射相对于文件映射,代表这个映射的vma没有对应到文件。对于用户空间普通的内存分配(堆空间、栈空间),都属于匿名映射。
显然,多个进程可能通过各自的文件映射来映射到同一个文件上(比如大多数进程都映射了libc库的so文件);那匿名映射呢?实际上,多个进程也可能通过各自的匿名映射来映射到同一段物理内存上,这种情况是由于fork之后父子进程共享原来的物理内存(copy-on-write)而引起的。
文件映射又分为共享映射和私有映射。私有映射时,如果进程对映射的地址空间进行写操作,则映射对应的磁盘高速缓存并不会直接被写。而是将原有内容复制一份,然后再写这个复制品,并且当前进程的对应页面映射将切换到这个复制品上去(写时复制)。也就是说,写操作是只有自己可见的。而对于共享映射,写操作则会影响到磁盘高速缓存,是大家都可见的。
4、内存管理架构
针对上图进行说明:
【
地址映射】(图:左中)
linux内核使用页式内存管理,应用程序给出的内存地址是虚拟地址,它需要经过若干级页表一级一级的变换,才变成真正的物理地址。
想一下,地址映射还是一件很恐怖的事情。当访问一个由虚拟地址表示的内存空间时,需要先经过若干次的内存访问,得到每一级页表中用于转换的页表项(页表是存放在内存里面的),才能完成映射。也就是说,要实现一次内存访问,实际上内存被访问了N+1次(N=页表级数),并且还需要做N次加法运算。
所以,地址映射必须要有硬件支持,mmu(内存管理单元)就是这个硬件。并且需要有cache来保存页表,这个cache就是TLB(Translation lookaside buffer)。
尽管如此,地址映射还是有着不小的开销。假设cache的访存速度是内存的10倍,命中率是40%,页表有三级,那么平均一次虚拟地址访问大概就消耗了两次物理内存访问的时间。
于是,一些嵌入式硬件上可能会放弃使用mmu,这样的硬件能够运行VxWorks(一个很高效的嵌入式实时操作系统)、linux(linux也有禁用mmu的编译选项)、等系统。
但是使用mmu的优势也是很大的,最主要的是出于安全性考虑。各个进程都是相互独立的虚拟地址空间,互不干扰。而放弃地址映射之后,所有程序将运行在同一个地址空间。于是,在没有mmu的机器上,一个进程越界访存,可能引起其他进程莫名其妙的错误,甚至导致内核崩溃。
在地址映射这个问题上,内核只提供页表,实际的转换是由硬件去完成的。那么内核如何生成这些页表呢?这就有两方面的内容,虚拟地址空间的管理和物理内存的管理。(实际上只有用户态的地址映射才需要管理,内核态的地址映射是写死的。)
想一下,地址映射还是一件很恐怖的事情。当访问一个由虚拟地址表示的内存空间时,需要先经过若干次的内存访问,得到每一级页表中用于转换的页表项(页表是存放在内存里面的),才能完成映射。也就是说,要实现一次内存访问,实际上内存被访问了N+1次(N=页表级数),并且还需要做N次加法运算。
所以,地址映射必须要有硬件支持,mmu(内存管理单元)就是这个硬件。并且需要有cache来保存页表,这个cache就是TLB(Translation lookaside buffer)。
尽管如此,地址映射还是有着不小的开销。假设cache的访存速度是内存的10倍,命中率是40%,页表有三级,那么平均一次虚拟地址访问大概就消耗了两次物理内存访问的时间。
于是,一些嵌入式硬件上可能会放弃使用mmu,这样的硬件能够运行VxWorks(一个很高效的嵌入式实时操作系统)、linux(linux也有禁用mmu的编译选项)、等系统。
但是使用mmu的优势也是很大的,最主要的是出于安全性考虑。各个进程都是相互独立的虚拟地址空间,互不干扰。而放弃地址映射之后,所有程序将运行在同一个地址空间。于是,在没有mmu的机器上,一个进程越界访存,可能引起其他进程莫名其妙的错误,甚至导致内核崩溃。
在地址映射这个问题上,内核只提供页表,实际的转换是由硬件去完成的。那么内核如何生成这些页表呢?这就有两方面的内容,虚拟地址空间的管理和物理内存的管理。(实际上只有用户态的地址映射才需要管理,内核态的地址映射是写死的。)
【
虚拟地址】(图:左下)
每个进程对应一个task结构,它指向一个mm结构,这就是该进程的内存管理器。(对于线程来说,每个线程也都有一个task结构,但是它们都指向同一个mm,所以地址空间是共享的。)
mm->pgd指向容纳页表的内存,每个进程有自已的mm,每个mm有自己的页表。于是,进程调度时,页表被切换(一般会有一个CPU寄存器来保存页表的地址,比如X86下的CR3,页表切换就是改变该寄存器的值)。所以,各个进程的地址空间互不影响(因为页表都不一样了,当然无法访问到别人的地址空间上。但是共享内存除外,这是故意让不同的页表能够访问到相同的物理地址上)。
用户程序对内存的操作(分配、回收、映射、等)都是对mm的操作,具体来说是对mm上的vma(虚拟内存空间)的操作。这些vma代表着进程空间的各个区域,比如堆、栈、代码区、数据区、各种映射区、等等。
用户程序对内存的操作并不会直接影响到页表,更不会直接影响到物理内存的分配。比如malloc成功,仅仅是改变了某个vma,页表不会变,物理内存的分配也不会变。
假设用户分配了内存,然后访问这块内存。由于页表里面并没有记录相关的映射,CPU产生一次缺页异常。内核捕捉异常,检查产生异常的地址是不是存在于一个合法的vma中。如果不是,则给进程一个"段错误",让其崩溃;如果是,则分配一个物理页,并为之建立映射。
mm->pgd指向容纳页表的内存,每个进程有自已的mm,每个mm有自己的页表。于是,进程调度时,页表被切换(一般会有一个CPU寄存器来保存页表的地址,比如X86下的CR3,页表切换就是改变该寄存器的值)。所以,各个进程的地址空间互不影响(因为页表都不一样了,当然无法访问到别人的地址空间上。但是共享内存除外,这是故意让不同的页表能够访问到相同的物理地址上)。
用户程序对内存的操作(分配、回收、映射、等)都是对mm的操作,具体来说是对mm上的vma(虚拟内存空间)的操作。这些vma代表着进程空间的各个区域,比如堆、栈、代码区、数据区、各种映射区、等等。
用户程序对内存的操作并不会直接影响到页表,更不会直接影响到物理内存的分配。比如malloc成功,仅仅是改变了某个vma,页表不会变,物理内存的分配也不会变。
假设用户分配了内存,然后访问这块内存。由于页表里面并没有记录相关的映射,CPU产生一次缺页异常。内核捕捉异常,检查产生异常的地址是不是存在于一个合法的vma中。如果不是,则给进程一个"段错误",让其崩溃;如果是,则分配一个物理页,并为之建立映射。
【
物理内存管理】(图:右上)
那么物理内存是如何分配的呢?
首先,linux支持NUMA(非均质存储结构),物理内存管理的第一个层次就是介质的管理。pg_data_t结构就描述了介质。一般而言,我们的内存管理介质只有内存,并且它是均匀的,所以可以简单地认为系统中只有一个pg_data_t对象。
每一种介质下面有若干个zone。一般是三个,DMA、NORMAL和HIGH。
DMA:因为有些硬件系统的DMA总线比系统总线窄,所以只有一部分地址空间能够用作DMA,这部分地址被管理在DMA区域(这属于是高级货了);
HIGH:高端内存。在32位系统中,地址空间是4G,其中内核规定3~4G的范围是内核空间,0~3G是用户空间(每个用户进程都有这么大的虚拟空间)(图:中下)。前面提到过内核的地址映射是写死的,就是指这3~4G的对应的页表是写死的,它映射到了物理地址的0~1G上。(实际上没有映射1G,只映射了896M。剩下的空间留下来映射大于1G的物理地址,而这一部分显然不是写死的)。所以,大于896M的物理地址是没有写死的页表来对应的,内核不能直接访问它们(必须要建立映射),称它们为高端内存(当然,如果机器内存不足896M,就不存在高端内存。如果是64位机器,也不存在高端内存,因为地址空间很大很大,属于内核的空间也不止1G了);
NORMAL:不属于DMA或HIGH的内存就叫NORMAL。
在zone之上的zone_list代表了分配策略,即内存分配时的zone优先级。一种内存分配往往不是只能在一个zone里进行分配的,比如分配一个页给内核使用时,最优先是从NORMAL里面分配,不行的话就分配DMA里面的好了(HIGH就不行,因为还没建立映射),这就是一种分配策略。
每个内存介质维护了一个mem_map,为介质中的每一个物理页面建立了一个page结构与之对应,以便管理物理内存。
每个zone记录着它在mem_map上的起始位置。并且通过free_area串连着这个zone上空闲的page。物理内存的分配就是从这里来的,从 free_area上把page摘下,就算是分配了。(内核的内存分配与用户进程不同,用户使用内存会被内核监督,使用不当就"段错误";而内核则无人监督,只能靠自觉,不是自己从free_area摘下的page就不要乱用。)
首先,linux支持NUMA(非均质存储结构),物理内存管理的第一个层次就是介质的管理。pg_data_t结构就描述了介质。一般而言,我们的内存管理介质只有内存,并且它是均匀的,所以可以简单地认为系统中只有一个pg_data_t对象。
每一种介质下面有若干个zone。一般是三个,DMA、NORMAL和HIGH。
DMA:因为有些硬件系统的DMA总线比系统总线窄,所以只有一部分地址空间能够用作DMA,这部分地址被管理在DMA区域(这属于是高级货了);
HIGH:高端内存。在32位系统中,地址空间是4G,其中内核规定3~4G的范围是内核空间,0~3G是用户空间(每个用户进程都有这么大的虚拟空间)(图:中下)。前面提到过内核的地址映射是写死的,就是指这3~4G的对应的页表是写死的,它映射到了物理地址的0~1G上。(实际上没有映射1G,只映射了896M。剩下的空间留下来映射大于1G的物理地址,而这一部分显然不是写死的)。所以,大于896M的物理地址是没有写死的页表来对应的,内核不能直接访问它们(必须要建立映射),称它们为高端内存(当然,如果机器内存不足896M,就不存在高端内存。如果是64位机器,也不存在高端内存,因为地址空间很大很大,属于内核的空间也不止1G了);
NORMAL:不属于DMA或HIGH的内存就叫NORMAL。
在zone之上的zone_list代表了分配策略,即内存分配时的zone优先级。一种内存分配往往不是只能在一个zone里进行分配的,比如分配一个页给内核使用时,最优先是从NORMAL里面分配,不行的话就分配DMA里面的好了(HIGH就不行,因为还没建立映射),这就是一种分配策略。
每个内存介质维护了一个mem_map,为介质中的每一个物理页面建立了一个page结构与之对应,以便管理物理内存。
每个zone记录着它在mem_map上的起始位置。并且通过free_area串连着这个zone上空闲的page。物理内存的分配就是从这里来的,从 free_area上把page摘下,就算是分配了。(内核的内存分配与用户进程不同,用户使用内存会被内核监督,使用不当就"段错误";而内核则无人监督,只能靠自觉,不是自己从free_area摘下的page就不要乱用。)
【
建立地址映射】
内核需要物理内存时,很多情况是整页分配的,这在上面的mem_map中摘一个page下来就好了。比如前面说到的内核捕捉缺页异常,然后需要分配一个page以建立映射。
说到这里,会有一个疑问,内核在分配page、建立地址映射的过程中,使用的是虚拟地址还是物理地址呢?首先,内核代码所访问的地址都是虚拟地址,因为CPU指令接收的就是虚拟地址(地址映射对于CPU指令是透明的)。但是,建立地址映射时,内核在页表里面填写的内容却是物理地址,因为地址映射的目标就是要得到物理地址。
那么,内核怎么得到这个物理地址呢?其实,上面也提到了,mem_map中的page就是根据物理内存来建立的,每一个page就对应了一个物理页。
于是我们可以说,虚拟地址的映射是靠这里page结构来完成的,是它们给出了最终的物理地址。然而,page结构显然是通过虚拟地址来管理的(前面已经说过,CPU指令接收的就是虚拟地址)。那么,page结构实现了别人的虚拟地址映射,谁又来实现page结构自己的虚拟地址映射呢?没人能够实现。
这就引出了前面提到的一个问题,内核空间的页表项是写死的。在内核初始化时,内核的地址空间就已经把地址映射写死了。page结构显然存在于内核空间,所以它的地址映射问题已经通过“写死”解决了。
由于内核空间的页表项是写死的,又引出另一个问题,NORMAL(或DMA)区域的内存可能被同时映射到内核空间和用户空间。被映射到内核空间是显然的,因为这个映射已经写死了。而这些页面也可能被映射到用户空间的,在前面提到的缺页异常的场景里面就有这样的可能。映射到用户空间的页面应该优先从HIGH区域获取,因为这些内存被内核访问起来很不方便,拿给用户空间再合适不过了。但是HIGH区域可能会耗尽,或者可能因为设备上物理内存不足导致系统里面根本就没有HIGH区域,所以,将NORMAL区域映射给用户空间是必然存在的。
但是NORMAL区域的内存被同时映射到内核空间和用户空间并没有问题,因为如果某个页面正在被内核使用,对应的page应该已经从free_area被摘下,于是缺页异常处理代码中不会再将该页映射到用户空间。反过来也一样,被映射到用户空间的page自然已经从free_area被摘下,内核不会再去使用这个页面。
说到这里,会有一个疑问,内核在分配page、建立地址映射的过程中,使用的是虚拟地址还是物理地址呢?首先,内核代码所访问的地址都是虚拟地址,因为CPU指令接收的就是虚拟地址(地址映射对于CPU指令是透明的)。但是,建立地址映射时,内核在页表里面填写的内容却是物理地址,因为地址映射的目标就是要得到物理地址。
那么,内核怎么得到这个物理地址呢?其实,上面也提到了,mem_map中的page就是根据物理内存来建立的,每一个page就对应了一个物理页。
于是我们可以说,虚拟地址的映射是靠这里page结构来完成的,是它们给出了最终的物理地址。然而,page结构显然是通过虚拟地址来管理的(前面已经说过,CPU指令接收的就是虚拟地址)。那么,page结构实现了别人的虚拟地址映射,谁又来实现page结构自己的虚拟地址映射呢?没人能够实现。
这就引出了前面提到的一个问题,内核空间的页表项是写死的。在内核初始化时,内核的地址空间就已经把地址映射写死了。page结构显然存在于内核空间,所以它的地址映射问题已经通过“写死”解决了。
由于内核空间的页表项是写死的,又引出另一个问题,NORMAL(或DMA)区域的内存可能被同时映射到内核空间和用户空间。被映射到内核空间是显然的,因为这个映射已经写死了。而这些页面也可能被映射到用户空间的,在前面提到的缺页异常的场景里面就有这样的可能。映射到用户空间的页面应该优先从HIGH区域获取,因为这些内存被内核访问起来很不方便,拿给用户空间再合适不过了。但是HIGH区域可能会耗尽,或者可能因为设备上物理内存不足导致系统里面根本就没有HIGH区域,所以,将NORMAL区域映射给用户空间是必然存在的。
但是NORMAL区域的内存被同时映射到内核空间和用户空间并没有问题,因为如果某个页面正在被内核使用,对应的page应该已经从free_area被摘下,于是缺页异常处理代码中不会再将该页映射到用户空间。反过来也一样,被映射到用户空间的page自然已经从free_area被摘下,内核不会再去使用这个页面。
【
内核空间管理】(图:右下)
除了对内存整页的使用,有些时候,内核也需要像用户程序使用malloc一样,分配一块任意大小的空间。这个功能是由slab系统来实现的。
slab相当于为内核中常用的一些结构体对象建立了对象池,比如对应task结构的池、对应mm结构的池、等等。
而slab也维护有通用的对象池,比如"32字节大小"的对象池、"64字节大小"的对象池、等等。内核中常用的kmalloc函数(类似于用户态的malloc)就是在这些通用的对象池中实现分配的。
slab除了对象实际使用的内存空间外,还有其对应的控制结构。有两种组织方式,如果对象较大,则控制结构使用专门的页面来保存;如果对象较小,控制结构与对象空间使用相同的页面。
除了slab,linux 2.6还引入了mempool(内存池)。其意图是:某些对象我们不希望它会因为内存不足而分配失败,于是我们预先分配若干个,放在mempool中存起来。正常情况下,分配对象时是不会去动mempool里面的资源的,照常通过slab去分配。到系统内存紧缺,已经无法通过slab分配内存时,才会使用 mempool中的内容。
slab相当于为内核中常用的一些结构体对象建立了对象池,比如对应task结构的池、对应mm结构的池、等等。
而slab也维护有通用的对象池,比如"32字节大小"的对象池、"64字节大小"的对象池、等等。内核中常用的kmalloc函数(类似于用户态的malloc)就是在这些通用的对象池中实现分配的。
slab除了对象实际使用的内存空间外,还有其对应的控制结构。有两种组织方式,如果对象较大,则控制结构使用专门的页面来保存;如果对象较小,控制结构与对象空间使用相同的页面。
除了slab,linux 2.6还引入了mempool(内存池)。其意图是:某些对象我们不希望它会因为内存不足而分配失败,于是我们预先分配若干个,放在mempool中存起来。正常情况下,分配对象时是不会去动mempool里面的资源的,照常通过slab去分配。到系统内存紧缺,已经无法通过slab分配内存时,才会使用 mempool中的内容。
【
用户的栈】
与堆一样,栈也是一个vma(图:左中),这个vma是一端固定、一端可伸(注意,不能缩)的。这个vma比较特殊,没有类似brk的系统调用让这个vma伸展,它是自动伸展的。
当用户访问的虚拟地址越过这个vma时,内核会在处理缺页异常的时候将自动将这个vma增大。内核会检查当时的栈寄存器(如:ESP),访问的虚拟地址不能超过ESP加n(n为CPU压栈指令一次性压栈的最大字节数)。也就是说,内核是以ESP为基准来检查访问是否越界。
但是,ESP的值是可以由用户态程序自由读写的,用户程序如果调整ESP,将栈划得很大很大怎么办呢?内核中有一套关于进程限制的配置,其中就有栈大小的配置,栈只能这么大,再大就出错。
对于一个进程来说,栈一般是可以被伸展得比较大(如:8MB)。然而对于线程呢?
首先线程的栈是怎么回事?前面说过,线程的mm是共享其父进程的。虽然栈是mm中的一个vma,但是线程不能与其父进程共用这个vma(两个运行实体显然不用共用一个栈)。于是,在线程创建时,线程库通过mmap新建了一个vma,以此作为线程的栈(大于一般为:2M)。
可见,线程的栈在某种意义上并不是真正栈,它是一个固定的区域,并且容量很有限。
当用户访问的虚拟地址越过这个vma时,内核会在处理缺页异常的时候将自动将这个vma增大。内核会检查当时的栈寄存器(如:ESP),访问的虚拟地址不能超过ESP加n(n为CPU压栈指令一次性压栈的最大字节数)。也就是说,内核是以ESP为基准来检查访问是否越界。
但是,ESP的值是可以由用户态程序自由读写的,用户程序如果调整ESP,将栈划得很大很大怎么办呢?内核中有一套关于进程限制的配置,其中就有栈大小的配置,栈只能这么大,再大就出错。
对于一个进程来说,栈一般是可以被伸展得比较大(如:8MB)。然而对于线程呢?
首先线程的栈是怎么回事?前面说过,线程的mm是共享其父进程的。虽然栈是mm中的一个vma,但是线程不能与其父进程共用这个vma(两个运行实体显然不用共用一个栈)。于是,在线程创建时,线程库通过mmap新建了一个vma,以此作为线程的栈(大于一般为:2M)。
可见,线程的栈在某种意义上并不是真正栈,它是一个固定的区域,并且容量很有限。