现在的位置: 首页 > 综合 > 正文

Linux内存管理(一)

2013年12月13日 ⁄ 综合 ⁄ 共 9698字 ⁄ 字号 评论关闭

Linux内存管理

摘要:本章首先以应用程序开发者的角度审视Linux的进程内存管理,在此基础上逐步深入到内核中讨论系统物理内存管理和内核内存的使用方法。力求从外到内、水到渠成地引导网友分析Linux的内存管理与使用。在本章最后,我们给出一个内存映射的实例,帮助网友们理解内核内存管理与用户内存管理之间的关系,希望大家最终能驾驭Linux内存管理。

前言

内存管理一向是所有操作系统书籍不惜笔墨重点讨论的内容,无论市面上或是网上都充斥着大量涉及内存管理的教材和资料。因此,我们这里所要写的Linux内存管理采取避重就轻的策略,从理论层面就不去班门弄斧,贻笑大方了。我们最想做的和可能做到的是从开发者的角度谈谈对内存管理的理解,最终目的是把我们在内核开发中使用内存的经验和对Linux内存管理的认识与大家共享。

当然,这其中我们也会涉及到一些诸如段页等内存管理的基本理论,但我们的目的不是为了强调理论,而是为了指导理解开发中的实践,所以仅仅点到为止,不做深究。

遵循“理论来源于实践”的“教条”,我们先不必一下子就钻入内核里去看系统内存到底是如何管理,那样往往会让你陷入似懂非懂的窘境(我当年就犯了这个错误!)。所以最好的方式是先从外部(用户编程范畴)来观察进程如何使用内存,等到大家对内存的使用有了较直观的认识后,再深入到内核中去学习内存如何被管理等理论知识。最后再通过一个实例编程将所讲内容融会贯通。

进程与内存

进程如何使用内存?

毫无疑问,所有进程(执行的程序)都必须占用一定数量的内存,它或是用来存放从磁盘载入的程序代码,或是存放取自用户输入的数据等等。不过进程对这些内存的管理方式因内存用途不一而不尽相同,有些内存是事先静态分配和统一回收的,而有些却是按需要动态分配和回收的。

对任何一个普通进程来讲,它都会涉及到5种不同的数据段。稍有编程知识的朋友都能想到这几个数据段中包含有“程序代码段”、“程序数据段”、“程序堆栈段”等。不错,这几种数据段都在其中,但除了以上几种数据段之外,进程还另外包含两种数据段。下面我们来简单归纳一下进程对应的内存空间中所包含的5种不同的数据区。

代码段:代码段是用来存放可执行文件的操作指令,也就是说是它是可执行程序在内存中的镜像。代码段需要防止在运行时被非法修改,所以只准许读取操作,而不允许写入(修改)操作――它是不可写的。

数据段:数据段用来存放可执行文件中已初始化全局变量,换句话说就是存放程序静态分配[1]的变量和全局变量。

BSS[2]BSS段包含了程序中未初始化的全局变量,在内存中
bss
段全部置零。

堆(heap:堆是用于存放进程运行中被动态分配的内存段,它的大小并不固定,可动态扩张或缩减。当进程调用malloc等函数分配内存时,新分配的内存就被动态添加到堆上(堆被扩张);当利用free等函数释放内存时,被释放的内存从堆中被剔除(堆被缩减)

是用户存放程序临时创建的局部变量,也就是说我们函数括弧“{}”中定义的变量(但不包括static声明的变量,static意味着在数据段中存放变量)。除此以外,在函数被调用时,其参数也会被压入发起调用的进程中,并且待到调用结束后,函数的返回值也会被存放回中。由于的先进先出特点,所以特别方便用来保存/恢复调用现场。从这个意义上讲,我们可以把堆栈看成一个寄存、交换临时数据的内存区。

进程如何组织这些区域?

上述几种内存区域中数据段、BSS和堆通常是被连续存储的――内存位置上是连续的,而代码段和往往会被独立存放。有趣的是,堆和两个区域关系很“暧昧”,他们一个向下“长”(i386体系结构中向下、堆向上),一个向上“长”,相对而生。但你不必担心他们会碰头,因为他们之间间隔很大(到底大到多少,你可以从下面的例子程序计算一下),绝少有机会能碰到一起。

下图简要描述了进程内存区域的分布:

数据段

BSS

代码段

“事实胜于雄辩”,我们用一个小例子(原形取自《User-Level Memory Management)来展示上面所讲的各种内存区的差别与位置。

#include<stdio.h>

#include<malloc.h>

#include<unistd.h>

int
bss_var;

int data_var0=1;

int main(int
argc,char **argv)

{

 
printf("below are addresses of types of process's
mem/n");

 
printf("Text location:/n");

 
printf("/tAddress of main(Code Segment):%p/n",main);

 
printf("____________________________/n");

 
int stack_var0=2;

 
printf("Stack Location:/n");

 
printf("/tInitial end of stack:%p/n",&stack_var0);

 
int stack_var1=3;

 
printf("/tnew end of stack:%p/n",&stack_var1);

 
printf("____________________________/n");

 
printf("Data Location:/n");

 
printf("/tAddress of
data_var(Data Segment):%p/n",&data_var0);

 
static int data_var1=4;

 
printf("/tNew end of
data_var(Data Segment):%p/n",&data_var1);

 
printf("____________________________/n");

 
printf("BSS Location:/n");

 
printf("/tAddress of
bss_var:%p/n",&bss_var);

 
printf("____________________________/n");

 
char *b = sbrk((ptrdiff_t)0);

 
printf("Heap Location:/n");

 
printf("/tInitial end of
heap:%p/n",b);

 
brk(b+4);

 
b=sbrk((ptrdiff_t)0);

 
printf("/tNew end of
heap:%p/n",b);

return 0;

 }

它的结果如下

below are addresses of types of process's
mem

Text location:

  
Address of main(Code Segment):0x8048388

____________________________

Stack Location:

  
Initial end of stack:0xbffffab4

  
new end of stack:0xbffffab0

____________________________

Data Location:

  
Address of data_var(Data Segment):0x8049758

  
New end of data_var(Data Segment):0x804975c

____________________________

BSS Location:

  
Address of bss_var:0x8049864

____________________________

Heap Location:

  
Initial end of heap:0x8049868

  
New end of heap:0x804986c

利用size命令也可以看到程序的各段大小,比如执行size example会得到

text
data bss dec hex filename

1654 280  
8 1942 796 example

但这些数据是程序编译的静态统计,而上面显示的是进程运行时的动态值,但两者是对应的。

 

通过前面的例子,我们对进程使用的逻辑内存分布已先睹为快。这部分我们就继续进入操作系统内核看看,进程对内存具体是如何进行分配和管理的。

从用户向内核看,所使用的内存表象形式会依次经历“逻辑地址”――“线性地址”――“物理地址”几种形式(关于几种地址的解释在前面已经讲述了)。逻辑地址经段机制转化成线性地址;线性地址又经过页机制转化为物理地址。(但是我们要知道Linux系统虽然保留了段机制,但是将所有程序的段地址都定死为0-4G,所以虽然逻辑地址和线性地址是两种不同的地址空间,但在Linux中逻辑地址就等于线性地址,它们的值是一样的)。沿着这条线索,我们所研究的主要问题也就集中在下面几个问题。

1.     进程空间地址如何管理?

2.     进程地址如何映射到物理内存?

3.    
物理内存如何被管理?

以及由上述问题引发的一些子问题。如系统虚拟地址分布内存分配接口;连续内存分配与非连续内存分配等。

 

进程内存空间

Linux操作系统采用虚拟内存管理技术,使得每个进程都有各自互不干涉的进程地址空间。该空间是块大小为4G的线性虚拟空间,用户所看到和接触到的都是该虚拟地址,无法看到实际的物理内存地址。利用这种虚拟地址不但能起到保护操作系统的效果(用户不能直接访问物理内存),而且更重要的是,用户程序可使用比实际物理内存更大的地址空间(具体的原因请看硬件基础部分)。

在讨论进程空间细节前,这里先要澄清下面几个问题:

l        
第一、4G的进程地址空间被人为的分为两个部分――用户空间与内核空间。用户空间从03G0xC0000000),内核空间占据3G4G。用户进程通常情况下只能访问用户空间的虚拟地址,不能访问内核空间虚拟地址。只有用户进程进行系统调用(代表用户进程在内核态执行)等时刻可以访问到内核空间。

l        
第二、用户空间对应进程,所以每当进程切换,用户空间就会跟着变化;而内核空间是由内核负责映射,它并不会跟着进程改变,是固定的。内核空间地址有自己对应的页表init_mm.pgd,用户进程各自有不同的页表。

l        
第三、每个进程的用户空间都是完全独立、互不相干的。不信的话,你可以把上面的程序同时运行10次(当然为了同时运行,让它们在返回前一同睡眠100秒吧),你会看到10个进程占用的线性地址一模一样。

 

进程内存管理

进程内存管理的对象是进程线性地址空间上的内存镜像这些内存镜像其实就是进程使用的虚拟内存区域(memory region)。进程虚拟空间是个3264位的“平坦”(独立的连续区间)地址空间(空间的具体大小取决于体系结构)。要统一管理这么大的平坦空间可绝非易事,为了方便管理,虚拟空间被划分为许多大小可变的(但必须是4096的倍数)内存区域,这些区域在进程线性地址中像停车位一样有序排列。这些区域的划分原则是“将访问属性一致的地址空间存放在一起”,所谓访问属性在这里无非指的是“可读、可写、可执行等”。

如果你要查看某个进程占用的内存区域,可以使用命令cat /proc/<pid>/maps获得(pid是进程号,你可以运行上面我们给出的例子――./example &;pid便会打印到屏幕),你可以发现很多类似于下面的数字信息。

由于程序example使用了动态库,所以除了example本身使用的内存区域外,还会包含那些动态库使用的内存区域(区域顺序是:代码段、数据段、bss段)。

我们下面只抽出和example有关的信息,除了前两行代表的代码段和数据段外,最后一行是进程使用的空间。

-------------------------------------------------------------------------------

08048000 - 08049000 r-xp 00000000
03:03 439029            
                  /home/mm/src/example

08049000 - 0804a000
rw
-p 00000000
03:03 439029                              
/home/mm/src/example

……………

bfffe000 - c0000000
rwxp
ffff000
00:00 0

----------------------------------------------------------------------------------------------------------------------

每行数据格式如下:

(内存区域)开始-结束 访问权限 
偏移  主设备号:次设备号 i节点 
文件。

注意,你一定会发现进程空间只包含三个内存区域,似乎没有上面所提到的堆、bss等,其实并非如此,程序内存段和进程地址空间中的内存区域是种模糊对应,也就是说,堆、bss、数据段(初始化过的)都在进程空间中由数据段内存区域表示。

 

Linux内核中对应进程内存区域的数据结构是:
vm_area_struct,
内核将每个内存区域作为一个单独的内存对象管理,相应的操作也都一致。采用面向对象方法使VMA结构体可以代表多种类型的内存区域--比如内存映射文件或进程的用户空间栈等,对这些区域的操作也都不尽相同。

vm_area_strcut结构比较复杂,关于它的详细结构请参阅相关资料。我们这里只对它的组织方法做一点补充说明。vm_area_struct是描述进程地址空间的基本管理单元,对于一个进程来说往往需要多个内存区域来描述它的虚拟空间,如何关联这些不同的内存区域呢?大家可能都会想到使用链表,的确vm_area_struct结构确实是以链表形式链接,不过为了方便查找,内核又以红黑树(以前的内核使用平衡树)的形式组织内存区域,以便降低搜索耗时。并存的两种组织形式,并非冗余:链表用于需要遍历全部节点的时候用,而红黑树适用于在地址空间中定位特定内存区域的时候。内核为了内存区域上的各种不同操作都能获得高性能,所以同时使用了这两种数据结构。

下图反映了进程地址空间的管理模型:

mmap

进程内存描述符

 

Vm_area_struct

进程虚拟地址

进程的地址空间对应的描述结构是“内存描述符结构,它表示进程的全部地址空间,――包含了和进程地址空间有关的全部信息,其中当然包含进程的内存区域。

进程内存的分配与回收

创建进程fork()、程序载入execve()、映射文件mmap()、动态内存分配malloc()/brk()等进程相关操作都需要分配内存给进程。不过这时进程申请和获得的还不是实际内存,而是虚拟内存,准确的说是“内存区域”。进程对内存区域的分配最终都会归结到do_mmap()函数上来(brk调用被单独以系统调用实现,不用do_mmap()),

内核使用do_mmap()函数创建一个新的线性地址区间。但是说该函数创建了一个新VMA并不非常准确,因为如果创建的地址区间和一个已经存在的地址区间相邻,并且它们具有相同的访问权限的话,那么两个区间将合并为一个。如果不能合并,那么就确实需要创建一个新的VMA了。但无论哪种情况,
do_mmap()
函数都会将一个地址区间加入到进程的地址空间中--无论是扩展已存在的内存区域还是创建一个新的区域。

同样,释放一个内存区域应使用函数do_ummap()它会销毁对应的内存区域。

如何由虚变实!

   
从上面已经看到进程所能直接操作的地址都为虚拟地址。当进程需要内存时,从内核获得的仅仅是虚拟的内存区域,而不是实际的物理地址,进程并没有获得物理内存(物理页面――页的概念请大家参考硬件基础一章),获得的仅仅是对一个新的线性地址区间的使用权。实际的物理内存只有当进程真的去访问新获取的虚拟地址时,才会由“请求页机制”产生“缺页”异常,从而进入分配实际页面的例程。

该异常是虚拟内存机制赖以存在的基本保证――它会告诉内核去真正为进程分配物理页,并建立对应的页表,这之后虚拟地址才实实在在地映射到了系统的物理内存上。(当然,如果页被换出到磁盘,也会产生缺页异常,不过这时不用再建立页表了)

这种请求页机制把页面的分配推迟到不能再推迟为止,并不急于把所有的事情都一次做完(这种思想有点像设计模式中的代理模式(proxy))。之所以能这么做是利用了内存访问的“局部性原理”,请求页带来的好处是节约了空闲内存,提高了系统的吞吐率。要想更清楚地了解请求页机制,可以看看《深入理解linux内核》一书。

这里我们需要说明在内存区域结构上的nopage操作。当访问的进程虚拟内存并未真正分配页面时,该操作便被调用来分配实际的物理页,并为该页建立页表项。在最后的例子中我们会演示如何使用该方法。

 

 

系统物理内存管理 

虽然应用程序操作的对象是映射到物理内存之上的虚拟内存,但是处理器直接操作的却是物理内存。所以当应用程序访问一个虚拟地址时,首先必须将虚拟地址转化成物理地址,然后处理器才能解析地址访问请求。地址的转换工作需要通过查询页表才能完成,概括地讲,地址转换需要将虚拟地址分段,使每段虚地址都作为一个索引指向页表,而页表项则指向下一级别的页表或者指向最终的物理页面。

每个进程都有自己的页表。进程描述符的pgd域指向的就是进程的页全局目录。下面我们借用《linux设备驱动程序》中的一幅图大致看看进程地址空间到物理页之间的转换关系。

 

 

     上面的过程说起来简单,做起来难呀。因为在虚拟地址映射到页之前必须先分配物理页――也就是说必须先从内核中获取空闲页,并建立页表。下面我们介绍一下内核管理物理内存的机制。

 

物理内存管理(页管理)

Linux内核管理物理内存是通过分页机制实现的,它将整个内存划分成无数个4k(i386体系结构中)大小的页,从而分配和回收内存的基本单位便是内存页了。利用分页管理有助于灵活分配内存地址,因为分配时不必要求必须有大块的连续内存[3],系统可以东一页、西一页的凑出所需要的内存供进程使用。虽然如此,但是实际上系统使用内存时还是倾向于分配连续的内存块,因为分配连续内存时,页表不需要更改,因此能降低TLB的刷新率(频繁刷新会在很大程度上降低访问速度)。

鉴于上述需求,内核分配物理页面时为了尽量减少不连续情况,采用了“伙伴”关系来管理空闲页面。伙伴关系分配算法大家应该不陌生――几乎所有操作系统方面的书都会提到,我们不去详细说它了,如果不明白可以参看有关资料。这里只需要大家明白Linux中空闲页面的组织和管理利用了伙伴关系,因此空闲页面分配时也需要遵循伙伴关系,最小单位只能是2的幂倍页面大小。内核中分配空闲页面的基本函数是get_free_page/get_free_pages,它们或是分配单页或是分配指定的页面(248…512页)。

 注意:get_free_page是在内核中分配内存,不同于malloc在用户空间中分配,malloc利用堆动态分配,实际上是调用brk()系统调用,该调用的作用是扩大或缩小进程堆空间(它会修改进程的brk域)。如果现有的内存区域不够容纳堆空间,则会以页面大小的倍数为单位,扩张或收缩对应的内存区域,但brk值并非以页面大小为倍数修改,而是按实际请求修改。因此Malloc在用户空间分配内存可以以字节为单位分配,但内核在内部仍然会是以页为单位分配的。

  
另外,需要提及的是,物理页在系统中由页结构struct
pag
e描述,系统中所有的页面都存储在数组mem_map[]中,可以通过该数组找到系统中的每一页(空闲或非空闲)。而其中的空闲页面则可由上述提到的以伙伴关系组织的空闲页链表(free_area[MAX_ORDER]索引。

 

空闲页框

APP

内存区域
vm_area_structs

mallocforkexcutemmap

brk/do_map

get_free_page(s)

用户空间

内核空间

进程虚拟地址空间

 

系统调用

进程页表

 

请页异常

文本框: 伙伴关系维护

内核内存使用

Slab

    所谓尺有所长,寸有所短。以页为最小单位分配内存对于内核管理系统中的物理内存来说的确比较方便,但内核自身最常使用的内存却往往是很小(远远小于一页)的内存块――比如存放文件描述符、进程描述符、虚拟内存区域描述符等行为所需的内存都不足一页。这些用来存放描述符的内存相比页面而言,就好比是面包屑与面包。一个整页中可以聚集多个这些小块内存;而且这些小块内存块也和面包屑一样频繁地生成/销毁。

 
为了满足内核对这种小内存块的需要,Linux系统采用了一种被称为slab分配器的技术。Slab分配器的实现相当复杂,但原理不难,其核心思想就是“存储池[4]的运用。内存片段(小块内存)被看作对象,当被使用完后,并不直接释放而是被缓存到“存储池”里,留做下次使用,这无疑避免了频繁创建与销毁对象所带来的额外负载。

Slab技术不但避免了内存内部分片(下文将解释)带来的不便(引入Slab分配器的主要目的是为了减少对伙伴系统分配算法的调用次数――频繁分配和回收必然会导致内存碎片――难以找到大块连续的可用内存,而且可以很好地利用硬件缓存提高访问速度。

  
 Slab
并非是脱离伙伴关系而独立存在的一种内存分配方式,slab仍然是建立在页面基础之上,换句话说,Slab将页面(来自于伙伴关系管理的空闲页面链表)撕碎成众多小内存块以供分配,slab中的对象分配和销毁使用kmem_cache_allockmem_cache_free

 

Kmalloc

Slab分配器不仅仅只用来存放内核专用的结构体,它还被用来处理内核对小块内存的请求。当然鉴于Slab分配器的特点,一般来说内核程序中对小于一页的小块内存的请求才通过Slab分配器提供的接口Kmalloc来完成(虽然它可分配32
131072字节的内存)。从内核内存分配的角度来讲,kmalloc可被看成是get_free_pages)的一个有效补充,内存分配粒度更灵活了。

有兴趣的话,可以到/proc/slabinfo中找到内核执行现场使用的各种slab信息统计,其中你会看到系统中所有slab的使用信息。从信息中可以看到系统中除了专用结构体使用的slab外,还存在大量为Kmalloc而准备的Slab(其中有些为dma准备的)。

 

 

内核非连续内存分配(Vmalloc

 

伙伴关系也好、slab技术也好,从内存管理理论角度而言目的基本是一致的,它们都是为了防止“分片”,不过分片又分为外部分片和内部分片之说,所谓内部分片是说系统为了满足一小段内存区(连续)的需要,不得不分配了一大区域连续内存给它,从而造成了空间浪费;外部分片是指系统虽有足够的内存,但却是分散的碎片,无法满足对大块“连续内存”的需求。无论何种分片都是系统有效利用内存的障碍。slab分配器使得一个页面内包含的众多小块内存可独立被分配使用,避免了内部分片,节约了空闲内存。伙伴关系把内存块按大小分组管理,一定程度上减轻了外部分片的危害,因为页框分配不在盲目,而是按照大小依次有序进行,不过伙伴关系只是减轻了外部分片,但并未彻底消除。你自己比划一下多次分配页面后,空闲内存的剩余情况吧。

所以避免外部分片的最终思路还是落到了如何利用不连续的内存块组合成“看起来很大的内存块”――这里的情况很类似于用户空间分配虚拟内存,内存逻辑上连续,其实映射到并不一定连续的物理内存上。Linux内核借用了这个技术,允许内核程序在内核地址空间中分配虚拟地址,同样也利用页表(内核页表)将虚拟地址映射到分散的内存页上。以此完美地解决了内核内存使用中的外部分片问题。内核提供vmalloc函数分配内核虚拟内存,该函数不同于kmalloc,它可以分配较Kmalloc大得多的内存空间(可远大于128K,但必须是页大小的倍数),但相比Kmalloc来说

抱歉!评论已关闭.