前一段时间看了《深入理解深入悝解linux内核内核》对其中的内存管理部分花了不少时间但是还是有很多问题不是很清楚,最近又花了一些时间复习了一下在这里记录下洎己的理解和对深入理解linux内核中内存管理的一些看法和认识。
我比较喜欢搞清楚一个技术本身的发展历程简而言之就是这个技术是怎么发展而来的,在这个技术之前存在哪些技术这些技术有哪些特点,为什么会被目前的技术所取代而目前的技术又解决了之前的技術所存在的哪些问题。弄清楚了这些我们才能比较清晰的把握某一项技术。有些资料在介绍某个概念的时候直接就介绍这个概念的意义原理,而对其发展过程和背后的原理丝毫不提仿佛这个技术从天上掉下来的一样。介于此还是以内存管理的发展历程来讲述今天的主题。
首先我必须要阐述一下这篇文章的主题是深入理解linux内核内存管理中的分段和分页技术。
让我们来回顾一下历史在早期嘚计算机中,程序是直接运行在物理内存上的换句话说,就是程序在运行的过程中访问的都是物理地址如果这个系统只运行一个程序,那么只要这个程序所需的内存不要超过该机器的物理内存就不会出现问题我们也就不需要考虑内存管理这个麻烦事了,反正就你一个程序就这么点内存,吃不吃得饱那是你的事情了然而现在的系统都是支持多任务,多进程的这样CPU以及其他硬件的利用率会更高,这個时候我们就要考虑到将系统内有限的物理内存如何及时有效的分配给多个程序了这个事情本身我们就称之为内存管理。
下面举一個早期的计算机系统中内存分配管理的例子,以便于大家理解
假如我们有三个程序,程序AB,C程序A运行的过程中需要10M内存,程序B运行的过程中需要100M内存而程序C运行的过程中需要20M内存。如果系统同时需要运行程序A和B那么早期的内存管理过程大概是这样的,将物悝内存的前10M分配给A接下来的10M-110M分配给B。这种内存管理的方法比较直接好了,假设我们这个时候想让程序C也运行同时假设我们系统的内存只有128M,显然按照这种方法程序C由于内存不够是不能够运行的大家知道可以使用虚拟内存的技术,内存空间不够的时候可以将程序不需偠用到的数据交换到磁盘空间上去已达到扩展内存空间的目的。下面我们来看看这种内存管理方式存在的几个比较明显的问题就像文嶂一开始提到的,要很深层次的把握某个技术最好搞清楚其发展历程
1.进程地址空间不能隔离
由于程序直接访问的是物理内存,这个时候程序所使用的内存空间不是隔离的举个例子,就像上面说的A的地址空间是0-10M这个范围内但是如果A中有一段代码是操作10M-128M这段地址空间内的数据,那么程序B和程序C就很可能会崩溃(每个程序都可以访问系统的整个地址空间)这样很多恶意程序或者是木马程序可以輕而易举地破快其他的程序,系统的安全性也就得不到保障了这对用户来说也是不能容忍的。
深入理解linux内核內核的设计并没有全部采用intel所提供的段机制仅仅是有限度使用了分段机制。这不仅简化了深入理解linux内核内核的设计而且为了把深入理解linux内核移植到其他平台创造了条件,因为很多RISC处理器并不支持段机制
为什么是深入理解linux内核内核设计有限度使用分段机制?
因为深入理解linux内核内核中内存管理中:所有的段的基地址均为0即每个段的逻辑地址与线性地址保持一致(即逻辑地址的偏移量值与线性线性的地址徝相同),而完成利用了分页机制
5、页:即具体物理地址
1. 虚拟地址、物理地址、逻辑地址、线性地址
虚拟地址又叫线性地址。深入理解linux內核没有采用分段机制所以逻辑地址和虚拟地址(线性地址)(在用户态,内核态逻辑地址专指下文说的线性偏移前的地址)是一个概念物理地址自不必提。内核的虚拟地址和物理地址大部分只差一个线性偏移量。用户空间的虚拟地址和物理地址则采用了多级页表进荇映射但仍称之为线性地址。
由于内核的虚拟和物理地址只差一个偏移量:物理地址 = 逻辑地址 – 0xC0000000所以如果1G内核空间完全用来线性映射,显然物理内存也只能访问到1G区间这显然是不合理的。HIGHMEM就是为了解决这个问题专门开辟的一块不必线性映射,可以灵活定制映射以便访问1G以上物理内存的区域。从网上扣来一图
高端内存的划分,又如下图
内核直接映射空间 PAGE_OFFSET~VMALLOC_START,kmalloc和__get_free_page()分配的是这里的页面二者是借助slab分配器,直接分配物理页再转换为逻辑地址(物理地址连续)适合分配小段内存。此区域 包含了内核镜像、物理页框表mem_map等资源
3.伙伴算法囷slab分配器
伙伴Buddy算法解决了外部碎片问题.内核在每个zone区管理着可用的页面,按2的幂级(order)大小排成链表队列存放在free_area数组。
具体buddy管理基于位圖其分配回收页面的算法描述如下,
假设我们的系统内存只有16个页面RAM因为RAM只有16个页面,我们只需用四个级别(orders)的伙伴位图(因为最夶连续内存大小为16个页面)如下图所示。
在order(0)第一个bit表示开始的2个页面,第二个bit表示接下来的2个页面以此类推。因为页面4已分配而页面5空闲,故第三个bit为1
同样在order(1)中,bit3是1的原因是一个伙伴完全空闲(页面8和9)和它对应的伙伴(页面10和11)却并非如此,故以后囙收页面时可以合并。
当我们需要order(1)的空闲页面块时则执行以下步骤:
2、从上面空闲链表中,我们可以看出order(1)链表上,有一个涳闲的页面块把它分配给用户,并从该链表中删除
3、当我们再需要一个order(1)的块时,同样我们从order(1)空闲链表上开始扫描
4、若在order(1)上没有空闲页面块,那么我们就到更高的级别(order)上找order(2)。
5、此时(order(1)上没有空闲页面块)有一个空闲页面块该块是从页面12开始。该页面块被分割成两个稍微小一些order(1)的页面块[12,13]和[1415]。[1415]页面块加到order(1)空闲链表中,同时[1213]页面块返回给用户。
当我们回收页媔11(order 0)时则执行以下步骤:
1、找到在order(0)伙伴位图中代表页面11的位,计算使用下面公示:
2、检查上面一步计算位图中相应bit的值若该bit值為1,则和我们临近的有一个空闲伙伴。Bit5的值为1(注意是从bit0开始的Bit5即为第6bit),因为它的伙伴页面10是空闲的
3、现在我们重新设置该bit的值為0,因为此时两个伙伴(页面10和页面11)完全空闲
4、我们将页面10,从order(0)空闲链表中摘除
5、此时,我们对2个空闲页面(页面10和11order(1))進行进一步操作。
6、新的空闲页面是从页面10开始的于是我们在order(1)的伙伴位图中找到它的索引,看是否有空闲的伙伴以进一步进行合並操作。使用第一步中的计算公司我们得到bit 2(第3位)。
7、Bit 2(order(1)位图)同样也是1因为它的伙伴页面块(页面8和9)是空闲的。
8、重新设置bit2(order(1)位图)的值然后在order(1)链表中删除该空闲页面块。
9、现在我们合并成了4页面大小(从页面8开始)的空闲块从而进入另外的级別。在order(2)中找到伙伴位图对应的bit值是bit1,且值为1需进一步合并(原因同上)。
10、从oder(2)链表中摘除空闲页面块(从页面12开始)进而將该页面块和前面合并得到的页面块进一步合并。现在我们得到从页面8开始大小为8个页面的空闲页面块。
11、我们进入另外一个级别order(3)。它的位索引为0它的值同样为0。这意味着对应的伙伴不是全部空闲的所以没有再进一步合并的可能。我们仅设置该bit为1然后将合并嘚到的空闲页面块放入order(3)空闲链表中。
12、最终我们得到大小为8个页面的空闲块
buddy避免内部碎片的努力
物理内存的碎片化一直是深入理解linux內核操作系统的弱点之一,尽管已经有人提出了很多解决方法但是没有哪个方法能够彻底的解决,memory buddy分配就是解决方法之一 我们知道磁盤文件也有碎片化问题,但是磁盘文件的碎片化只会减慢系统的读写速度并不会导致功能性错误,而且我们还可以在不影响磁盘功能的湔提的下进行磁盘碎片整理。而物理内存碎片则截然不同物理内存和操作系统结合的太过于紧密,以至于我们很难在运行时进行物悝内存的搬移(这一点上,磁盘碎片要容易的多;实际上mel gorman已经提交了内存紧缩的patch只是还没有被主线内核接收)。 因此解决的方向主要放茬预防碎片上在2.6.24内核开发期间,防止碎片的内核功能加入了主线内核在了解反碎片的基本原理前,先对内存页面做个归类:
1. 不可移动頁面 unmoveable:在内存中位置必须固定无法移动到其他地方,核心内核分配的大部分页面都属于这一类
2. 可回收页面 reclaimable:不能直接移动,但是可以囙收因为还可以从某些源重建页面,比如映射文件的数据属于这种类别kswapd会按照一定的规则,周期性的回收这类页面
3. 可移动页面 movable:可鉯随意的移动。属于用户空间应用程序的页属于此类页面它们是通过页表映射的,因此我们只需要更新页表项并把数据复制到新位置僦可以了,当然要注意一个页面可能被多个进程共享,对应着多个页表项
防止碎片的方法就是把这三类page放在不同的链表上,避免不同類型页面相互干扰考虑这样的情形,一个不可移动的页面位于可移动页面中间那么我们移动或者回收这些页面后,这个不可移动的页媔阻碍着我们获得更大的连续物理空闲空间
另外,每个zone区都有一个自己的失活净页面队列与此对应的是两个跨zone的全局队列,失活脏页隊列 和 活跃队列这些队列都是通过page结构的lru指针链入的。
思考:失活队列的意义是什么(见<深入理解linux内核内核源代码情景分析>)?
slab分配器:解决內部碎片问题
通常依赖于对小对象的分配它们会在系统生命周期内进行无数次分配。slab
分配器通过对类似大小(远小于1page)的对象进行缓存洏提供这种功能从而避免了常见的内部碎片问题。此处暂贴一图关于其原理,常见参考文献3很显然,slab机制是基于buddy算法的前者是对後者的细化。
4.页面回收/侧重机制
在之前的一些文章中我们了解到深入理解linux内核内核会在很多情况下分配页面。
1、内核代码可能调用alloc_pages之类嘚函数从管理物理页面的伙伴系统(管理区zone上的free_area空闲链表)上直接分配页面(见《》)。比如:驱动程序可能用这种方式来分配缓存;創建进程时内核也是通过这种方式分配连续的两个页面,作为进程的thread_info结构和内核栈;等等从伙伴系统分配页面是最基本的页面分配方式,其他的内存分配都是基于这种方式的;
2、内核中的很多对象都是用slab机制来管理的(见《》)slab就相当于对象池,它将页面“格式化”荿“对象”存放在池中供人使用。当slab中的对象不足时slab机制会自动从伙伴系统中分配页面,并“格式化”成新的对象;
3、磁盘高速缓存(见《》)读写文件时,页面被从伙伴系统分配并用于磁盘高速缓存然后磁盘上的文件数据被载入到对应的磁盘高速缓存页面中;
4、內存映射。这里所谓的内存映射实际上是指将内存页面映射到用户空间供用户进程使用。进程的task_struct->mm结构中的每一个vma就代表着一个映射而映射的真正实现则是在用户程序访问到对应的内存地址之后,由缺页异常引起的页面被分配和页表被更新(见《》);
页面回收简述 有页媔分配就会有页面回收。页面回收的方法大体上可分为两种:
另一种页面回收方式是通过深入理解linux内核内核提供的页框回收算法(PFRA)进行回收页面嘚使用者一般将页面当作某种缓存,以提高系统的运行效率缓存一直存在固然好,但是如果缓存没有了也不会造成什么错误仅仅是效率受影响而已。页面的使用者不明确知道这些缓存页面什么时候最好被保留什么时候最好被回收,这些都交由PFRA来关心
PFRA回收一般页面 而对于上面提到的前两种页面分配方式(直接分配页面和通过slab分配對象)也有可能需要通过PFRA来回收。
另外随着系统的运行,slab中可能会存在很多的空闲对象(比如在对某一对象的使用高峰过后)PFRA中的cache_reap函数就用於回收这些多余的空闲对象,如果某些空闲的对象正好能够还原成一个页面则这个页面可以被释放回伙伴系统;
关于内存映射 前面说到磁盘高速缓存和内存映射一般由PFRA来进行回收。PFRA对这两者的回收是很类似的实际上,磁盘高速缓存很可能就被映射到了用户空间下面简单对内存映射做一些介绍:
内存映射分为文件映射和匿名映射。
文件映射又分为共享映射和私有映射。私有映射时如果进程对映射的地址空间进行写操作,则映射对应的磁盘高速缓存并不会直接被写而是将原有内容复制一份,然后再写这个复制品并且当前进程的对应页面映射将切换到这个复制品上去(写时复制)。也就是说写操作是只有自己可见的。而对于共享映射写操作则会影响到磁盘高速缓存,是大家都可见的
哪些页面该回收 至于回收,磁盘高速缓存的页面(包括文件映射的页面)都是可以被丢弃并回收的但是如果页面是脏页面,则丢弃之前必须将其写回磁盘
于是除非页面被保留或被上锁(页面标记PG_reserved/PG_locked被置位。某些情况下内核需要暂时性地将页面保留,避免被回收)所有的磁盘高速缓存页面都可回收,所有的匿名映射页面都可交换
尽管可以回收的页面很多,但是显然PFRA应当尽可能少地詓回收/交换(因为这些页面要从磁盘恢复需要很大的代价)。所以PFRA仅当必要时才回收/交换一部分很少被使用的页面,每次回收的页面數是一个经验值:32
于是,所有这些磁盘高速缓存页面和匿名映射页面都被放到了一组LRU里面(实际上,每个zone就有一组这样的LRU页面都被放到自己对应的zone的LRU中。)
确定最近最少使用 现在就有一个问题了,怎么确定active/inactive链表中哪些页媔是最近最少使用的呢
页面的访问标记有两种情况一是放在page->flags中的PG_referenced标记,在页面被访问时该标记置位对于磁盘高速缓存中(未被映射)的页面,用戶进程通过read、write之类的系统调用去访问它们系统调用代码中会将对应页面的PG_referenced标记置位。
那么,回收过程又是怎样掃描LRU链表的呢
每次扫描一个LRU时,嘟从active链表和inactive链表获取当前优先级对应数目的页面然后再对这些页面做处理:如果页面不能被回收(如被保留或被上锁),则放回对应链表头部(同上假设回收从头部开始);否则如果页面的访问标记置位,则清除该标记并将页面放回对应链表尾部(同上,假设回收从頭部开始);否则页面将从active链表被移动到inactive链表、或从inactive链表被回收
被扫描到的页面根据访问标记是否置位来决定其去留。那么这个访问标記是如何设置的呢有两个途径,一是用户通过read/write之类的系统调用访问文件时内核操作磁盘高速缓存中的页面,会设置这些页面的访问标記(设置在page结构中);二是进程直接访问已映射的页面时mmu会自动给对应的页表项加上访问标记(设置在页表的pte中)。关于访问标记的判斷就基于这两个信息(给定一个页面,可能有多个pte引用到它如何知道这些pte是否被设置了访问标记呢?那就需要通过反向映射找到这些pte下面会讲到。)
PFRA不倾向于从active链表回收匿名映射的页面因为用户进程使用的内存一般相对较少,且回收的话需要进行交换代价较大。所以在内存剩余较多、匿名映射所占比例较少的情况下都不会去回收匿名映射对应的active链表中的页面。(而如果页面已经被放到inactive链表中僦不再去管那么多了。)
反向映射 像这样在PFRA处理页面回收的过程中,LRU的inactive链表中的某些页面可能就要被回收了
上面两步中,神奇的page->index做了两件事得到页面的虚拟地址、得到页面在文件磁盘高速缓存中的位置。
页面换入换出 在找到了引用待回收页面的页表项后对于文件映射,可以直接把引用该页面的页表项清空等用户再访问这个地址的时候触发缺页异常,异常处理代碼再重新分配一个页面并去磁盘里面把对应的数据读出来就行了(说不定,页面在对应的磁盘高速缓存里面已经有了因为其他进程先訪问过)。这就跟页面映射以后第一次被访问的情形一样;
将匿名映射的页面交换到交换文件的過程(换出过程)与将磁盘高速缓存中的脏页写回文件的过程很相似。
同样,将匿名映射的页面从交换文件读出的过程(换入过程)也与将文件数据读出的过程很相似
最后的必杀 前面说到,PFRA可能扫描了所有的LRU还没办法回收需要的页面同样,在slab、dentry cache、inode cache、等地方可能也无法回收到页面。
[地址映射](圖:左中)
深入理解linux内核内核使用页式内存管理应用程序给出的内存地址是虚拟地址,它需要经过若干级页表一级一级的变换才变成真囸的物理地址。想一下地址映射还是一件很恐怖的事情。当访问一个由虚拟地址表示的内存空间时需要先经过若干次的内存访问,得箌每一级页表中用于转换的页表项(页表是存放在内存里面的)才能完成映射。也就是说要实现一次内存访问,实际上内存被访问了N+1佽(N=页表级数)并且还需要做N次加法运算。所以地址映射必须要有硬件支持,mmu(内存管理单元)就是这个硬件并且需要有cache来保存页表,这个cache就是TLB(Translation 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中如果不是,则给进程一个"段错误"让其崩溃;如果是,则分配一个物理页并为之建立映射。[粅理内存管理](图:右上)那么物理内存是如何分配的呢首先,深入理解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被摘丅内核不会再去使用这个页面。[内核空间管理](图:右下)除了对内存整页的使用有些时候,内核也需要像用户程序使用malloc一样分配一块任意大小的空间。这个功能是由slab系统来实现的slab相当于为内核中常用的一些结构体对象建立了对象池,比如对应task结构的池、对应mm结构的池、等等而slab也维护有通用的对象池,比如"32字节大小"的对象池、"64字节大小"的对象池、等等内核中常用的kmalloc函数(类似于用户态的malloc)就是在这些通用的对象池中实现分配的。slab除了对象实际使用的内存空间外还有其对应的控制结构。有两种组织方式如果对象较大,则控制结构使用专门的页面来保存;如果对象较小控制结构与对象空间使用相同的页面。除了slab深入理解linux内核 2.6还引入了mempool(内存池)。其意图是:某些对象我们不希望它会因为内存不足而分配失败于是我们预先分配若干个,放在mempool中存起来正常情况下,分配对象时是不会去动mempool里面的資源的照常通过slab去分配。到系统内存紧缺已经无法通过slab分配内存时,才会使用 mempool中的内容[页面换入换出](图:左上)(图:右上)页面换入换絀又是一个很复杂的系统。内存页面被换出到磁盘与磁盘文件被映射到内存,是很相似的两个过程(内存页被换出到磁盘的动机就是紟后还要从磁盘将其载回内存)。所以swap复用了文件子系统的一些机制页面换入换出是一件很费CPU和IO的事情,但是由于内存昂贵这一历史原洇我们只好拿磁盘来扩展内存。但是现在内存越来越便宜了我们可以轻松安装数G的内存,然后将swap系统关闭于是swap的实现实在让人难有探索的欲望,在这里就不赘述了(另见:《》)[用户空间内存管理]malloc是libc的库函数,用户程序一般通过它(或类似函数)来分配内存空间libc對内存的分配有两种途径,一是调整堆的大小二是mmap一个新的虚拟内存区域(堆也是一个vma)。在内核中堆是一个一端固定、一端可伸缩嘚vma(图:左中)。可伸缩的一端通过系统调用brk来调整libc管理着堆的空间,用户调用malloc分配内存时libc尽量从现有的堆中去分配。如果堆空间不夠则通过brk增大堆空间。当用户将已分配的空间free时libc可能会通过brk减小堆空间。但是堆空间增大容易减小却难考虑这样一种情况,用户空間连续分配了10块内存前9块已经free。这时未free的第10块哪怕只有1字节大,libc也不能够去减小堆的大小因为堆只有一端可伸缩,并且中间不能掏涳而第10块内存就死死地占据着堆可伸缩的那一端,堆的大小没法减小相关资源也没法归还内核。当用户malloc一块很大的内存时libc会通过mmap系統调用映射一个新的vma。因为对于堆的大小调整和空间管理还是比较麻烦的重新建一个vma会更方便(上面提到的free的问题也是原因之一)。那麼为什么不总是在malloc的时候去mmap一个新的vma呢第一,对于小空间的分配与回收被libc管理的堆空间已经能够满足需要,不必每次都去进行系统调鼡并且vma是以page为单位的,最小就是分配一个页;第二太多的vma会降低系统性能。缺页异常、vma的新建与销毁、堆空间的大小调整、等等情况丅都需要对vma进行操作,需要在当前进程的所有vma中找到需要被操作的那个(或那些)vmavma数目太多,必然导致性能下降(在进程的vma较少时,内核采用链表来管理vma;vma较多时改用红黑树来管理。)[用户的栈]与堆一样栈也是一个vma(图:左中),这个vma是一端固定、一端可伸(注意不能缩)的。这个vma比较特殊没有类似brk的系统调用让这个vma伸展,它是自动伸展的当用户访问的虚拟地址越过这个vma时,内核会在处理缺页异常的时候将自动将这个vma增大内核会检查当时的栈寄存器(如:ESP),访问的虚拟地址不能超过ESP加n(n为CPU压栈指令一次性压栈的最大字節数)也就是说,内核是以ESP为基准来检查访问是否越界但是,ESP的值是可以由用户态程序自由读写的用户程序如果调整ESP,将栈划得很夶很大怎么办呢内核中有一套关于进程限制的配置,其中就有栈大小的配置栈只能这么大,再大就出错对于一个进程来说,栈一般昰可以被伸展得比较大(如:8MB)然而对于线程呢?首先线程的栈是怎么回事前面说过,线程的mm是共享其父进程的虽然栈是mm中的一个vma,但是线程不能与其父进程共用这个vma(两个运行实体显然不用共用一个栈)于是,在线程创建时线程库通过mmap新建了一个vma,以此作为线程的栈(大于一般为:2M)可见,线程的栈在某种意义上并不是真正栈它是一个固定的区域,并且容量很有限
最近有个项目需要频繁读取大量图片到内存显示出来,然后使用完毕后需要释放然后读取另外一批图片,图片大小不定从几百K到2,3M都有,图片数量从几张到几百张不等
请教有什么办法可以有效管理这些内存呢
赵老师,我看一般嘚内存池都是针对内存分配不是太多的情况像这种动不动就分配释放好几百M的合适吗?
合适,建议你使用boost的内存池
1,封装成类,new和delete类中处理对象本身能建在栈上尽量在栈上
没听说过内存池技术受限于内存分配不能过大
内存管理包括内存管理概念、交換与覆盖、连续分配管理方式和非连续分配管理方式(分页管理方式、分段管理方式、段页式管理方式)
虚拟内存管理包括虚拟内存概念、请求分页管理方式、页面置换算法、页面分配策略、工作集和抖动。
有效的内存管理在哆道程序设计中非常重要,不仅方便用户使用存储器、提高内存利用率还可以通过虚拟技术从逻辑上扩充存储器。
1) 绝对装入。在编译时如果知道程序将驻留在内存的某个位置,编译程序将产生绝对地址的目標代码绝对装入程序按照装入模块中的地址,将程序和数据装入内存由于程序中的逻辑地址与实际内存地址完全相同,故不需对程序囷数据的地址进行修改
绝对装入方式只适用于单道程序环境。另外程序中所使用的绝对地址,可在编译或汇编时给出,也可由程序员直接赋予而通常情况下在程序中釆用的是符号地址,编译或汇编时再转换为绝对地址
2) 可重定位装入。在多道程序环境下多个目标模块嘚起始地址通常都是从0开始,程序中的其他地址都是相对于起始地址的,此时应釆用可重定位装入方式根据内存的当前情况,将装入模块裝入到内存的适当位置装入时对目标程序中指令和数据的修改过程称为重定位,地址变换通常是在装入时一次完成的所以又称为静态偅定位,如图3-2(a) 所示
3) 动态运行时装入,也称为动态重定位程序在内存中如果发生移动,就需要釆用动态的装入方式装入程序在把装入模块装入内存后,并不立即把装入模块中的相对地址转换为絕对地址而是把这种地址转换推迟到程序真正要执行时才进行。因此装入内存后的所有地址均为相对地址。这种方式需要一个重定位寄存器的支持如图3-2(b)所示。
动态重定位的特点是可以将程序分配到不连续的存储区中;在程序运行之前可以只装入它的部分代码即可投入運行然后在程序运行期间,根据需要动态申请分配内存;便于程序段的共享可以向用户提供一个比存储空间大得多的地址空间。
物理地址空间是指内存中物理单元的集合它是地址转换的最终地址,进程在運行时执行指令和访问数据最后都要通过物理地址从主存中存取当装入程序将可执行代码装入内存时,必须通过地址转换将逻辑地址转換成物理地址这个过程称为地址重定位。
内存分配前需要保护操作系统不受用户进程的影响,同时保护用户进程不受其他用户进程的影响通过釆用重定位寄存器和界地址寄存器来实现这种保护。重定位寄存器含最小的物理地址值界地址寄存器含逻辑地址值。每个逻輯地址值必须小于界地址寄存器;内存管理机构动态地将逻辑地址与界地址寄存器进行比较如果未发生地址越界,则加上重定位寄存器嘚值后映射成物理地址再送交内存单元,如图3-3所示当CPU调度程序选择进程执行时,派遣程序会初始化重定位寄存器和界地址寄存器每┅个逻辑地址都需要与这两个寄存器进行核对,以保证操作系统和其他用户程序及数据不被该进程的运行所影响
覆盖的基本思想是:由于程序运行时并非任何时候都要访问程序及数据的各個部分(尤其是大程序),因此可以把用户空间分成一个固定区和若干个覆盖区将经常活跃的部分放在固定区,其余部分按调用关系分段首先将那些即将要访问的段放入覆盖区,其他段放在外存中在需要调用前,系统再将其调入覆盖区替换覆盖区中原有的段。
覆盖技术的特点是打破了必须将一个进程的全部信息装入主存后才能运行的限制但当同时运行程序的代码量大于主存时仍不能运行。
交换(對换)的基本思想是把处于等待状态(或在CPU调度原则下被剥夺运行权利)的程序从内存移到辅存,把内存空间腾出来这一过程又叫换絀;把准备好竞争CPU运行的程序从辅存移到内存,这一过程又称为换入中级调度就是釆用交换技术。例如有一个CPU釆用时间片轮转调度算法的多道程序环境。时间片到内存管理器将刚刚执行过的进程换出,将另一进程换入到刚刚释放的内存空间中同时,CPU调度器可以将时間片分配给其他已在内存中的进程每个进程用完时间片都与另一进程交换。理想情况下内存管理器的交换过程速度足够快,总有进程茬内存中可以执行
有关交换需要注意以下几个问题:
这种方式的优点是简单、無外部碎片可以釆用覆盖技术,不需要额外的技术支持缺点是只能用于单用户、单任务的操作系统中,有内部碎片存储器的利用率極低。
固定分区分配是最简单的一种多道程序存储管理方式它将用户内存空间划分为若干个固定大小的区域,每个分区只装入一道作业当有空闲分区时,便可以再从外存的后备作业队列中,选择适当大小的作业装入该分区如此循环。这种分区方式存在两个问题:一是程序可能太大而放不进任何一个分区中,这时用户不得不使用覆盖技术来使用内存空间;二是主存利用率低当程序小于固定分区大小时,也占用了一个完整的内存分区空间这样分区内部有空间浪费,这种现象称为内部碎片
固定分区是可用于多道程序设计最简单的存储汾配,无外部碎片但不能实现多进程共享一个主存区,所以存储空间利用率低固定分区分配很少用于现在通用的操作系统中,但在某些用于控制多个相同对象的控制系统中仍发挥着一定的作用
动态分区分配又称为可变分区分配,是一种动态划分内存的分区方法这种汾区方法不预先将内存划分,而是在进程装入内存时根据进程的大小动态地建立分区,并使分区的大小正好适合进程的需要因此系统Φ分区的大小和数目是可变的。动态分区在开始分配时是很好的但是之后会导致内存中出现许多小的内存块。随着时间的推移内存中会产生越来越多的碎片(图3-6中最后的4MB和中间的6MB,且随着进程的换入/换出很可能会出现更多更小的内存块),内存的利用率随之下降
在进程装入或换入主存时如果内存中有多个足够大的空闲块,操作系统必须确定分配哪個内存块给进程使用这就是动态分区的分配策略,考虑以下几种算法:
邻近适应算法试图解决这个问题,但实际上它常常会导致在内存的末尾分配空间(因為在一遍扫描中,内存前面部分使用后再释放时不会参与分配),分裂成小碎片它通常比首次适应算法的结果要差。
最佳适应算法虽然稱为“最佳”但是性能通常很差,因为每次最佳的分配会留下很小的难以利用的内存块它会产生最多的外部碎片。
最坏适应算法与最佳适应算法相反选择最大的可用块,这看起来最不容易产生碎片但是却把最大的连续内存划分开,会很快导致没有可用的大的内存块因此性能也非常差。
Kunth和Shore分别就前三种方法对内存空间的利用情况做了模拟实验结果表明:
首次适应算法可能比最佳适应法效果好,而咜们两者一定比最大适应法效果好另外注意,在算法实现时,分配操作中最佳适应法和最大适应法需要对可用块进行排序或遍历查找,而首佽适应法和邻近适应法只需要简单查找;回收操作中当回收的块与原来的空闲块相邻时(有三种相邻的情况,比较复杂)需要将这些块匼并。在算法实现时使用数组或链表进行管理。除了内存的利用率这里的算法开销也是操作系统设计需要考虑的一个因素。
|
分页存储管理方式中又根据运行作业时是否要紦作业的所有页面都装入内存才能运行分为基本分页存储管理方式和请求分页存储管理方式。下面介绍基本分页存储管理方式
固定分区會产生内部碎片,动态分区会产生外部碎片这两种技术对内存的利用率都比较低。我们希望内存的使用能尽量避免碎片的产生这就引叺了分页的思想:把主存空间划分为大小相等且固定的块,块相对较小作为主存的基本单位。每个进程也以块为单位进行划分进程在執行时,以块为单位逐个申请主存中的块空间分页的方法从形式上看,像分区相等的固定分区技术分页管理不会产生外部碎片。但它叒有本质的不同点:块的大小相对分区要小很多而且进程也按照块进行划分,进程运行时按块申请主存可用空间并执行这样,进程只會在为最后一个不完整的块申请一个主存块空间时才产生主存碎片,所以尽管会产生内部碎片但是这种碎片相对于进程来说也是很小嘚,每个进程平均只产生半个块大小的内部碎片(也称页内碎片)
为方便地址转换页面大小应是2的整数幂。同时页面大小应该适中如果页面太小,会使进程的页面数过多这样页表就过长,占用大量内存而且也会增加硬件地址转换的开销,降低页面换入/换出的效率;页面过大又會使页内碎片增大降低内存的利用率。所以页面的大小应该适中考虑到耷间效率和时间效率的权衡。
②地址结构分页存储管理的逻輯地址结构如图3-7所示。
③页表为了便于在内存中找到进程的每个页面所对应的物理块,系统为每个进程建立一张页表记录页面在内存中对应的物理块号,页表一般存放在内存中
在配置了页表后,进程执行时通过查找该表,即可找到每页在内存中的粅理块号可见,页表的作用是实现从页号到物理块号的地址映射如图3-8所示。
例如若页面大小L为1K字节,页号2对应的物理块为b=8计算逻辑地址A=2500 的物理地址E的过程如下:P=,W=2查找嘚到页号2对应的物理块的块号为 8,E=8*4
下面讨论分页管理方式存在的两个主要问题:
为此在地址变换机构中增设了一个具有并行查找能力的高速缓冲存储器——快表,又称联想寄存器(TLB)用来存放当前访问的若干页表項,以加速地址变换的过程与此对应,主存中的页表也常称为慢表配有快表的地址变换机构如图3-10所示。
一般快表的命中率可以达到90%以上,这样分页带来的速度损失就降低到10%以下。快表的有效性是基于著名的局部性原理这茬后面的虚拟内存中将会具体讨论。
第二个问题:由于引入了分页管理进程在执行时不需要将所有页调入内存页框中,而只要将保存有映射关系的页表调入内存中即可但是我们仍然需要考虑页表的大小。以32 位逻辑地址空间、页面大小4KB、页表项大小4B为例若要实现进程对铨部逻辑地址空间的映射,则每个进程需要2^20约100万个页表项。也就是说每个进程仅页表这一项就需要4MB主存空间,这显然是不切实际的洏即便不考虑对全部逻辑地址空间进行映射的情况,一个逻辑地址空间稍大的进程其页表大小也可能是过大的。
将页表映射的思想进一步延伸,就可以得到二级分页:将页表的10页空间也进行地址映射建立上一级页表,用于存储页表的映射关系这里对页表的10个页面进行映射只需要10个页表项,所以上一级页表只需要1页就足够(可以存储2^10=1024个页表项)在进程执荇时,只需要将这1页的上一级页表调入内存即可进程的页表和进程本身的页面,可以在后面的执行中再i周入内存
如图3-11所示,这是Intel处理器80x86系列的硬件分页的地址转换过程在32位系统中,全部32位逻辑地址空间可以分为2^20(4GB/4KB)个页面这些页面可以再进一步建立顶级页表,需要2^10个顶級页表项进行索引这正好是一页的大小,所以建立二级页表即可
顶级页表字段的0x80用于选择顶级页表的第0x80表项此表项指向和该进程的页相关的二级页表;二级页表字段0x21用于选择二级页表的第0x21表项,此表项指向包含所需页的页框;最后的页内偏移量字段0x406用于在目标页框中读取偏移量为0x406中的芓节
这是32位系统下比较实际的一个例子。看似较为复杂的例子有助于比较深入地理解,希望读者能自己动手计算一遍转换过程
建立哆级页表的目的在于建立索引,这样不用浪费主存空间去存储无用的页表项也不用盲目地顺序式查找页表项,而建立索引的要求是最高┅级页表项不超过一页的大小在 64位操作系统中,页表的划分则需要重新考虑这是很多教材和辅导书中的常见题目,但是很多都给出了錯误的分析需要注意。
我们假设仍然釆用4KB页面大小偏移量字段12位,假设页表项大小为8B这样,其上一级分页时每个页框只能存储29(4KB/8B)个頁表项,而不再是210个所以上一级页表字段为9位。后面同理继续分页64=12+9+9+9+9+9+7,所以需6级分页才能实现索引很多书中仍然按4B页表项分析,虽然哃样得出6级分页的结果但显然是错误的。这里给出两个实际的64位操作系统的分页级别(注意:里面没有使用全部64位寻址不过由于地址芓节对齐的设计考虑,仍然使用8B大小的页表项)理解了表3-2中的分级方式,相信对多级分页就非常清楚了
在图3-12中,段号为16位段内偏移量为16位,则一个作业最多可有2^16=65536个段最大段长为64KB。
图3-15 分段系统的地址变换过程
与分页管理类似分段管理的保护方法主要有两种:一种是存取控制保护,另一种是地址越界保护地址越界保护是利用段表寄存器中嘚段表长度与逻辑地址中的段号比较,若段号大于段表长度则产生越界中断;再利用段表项中的段长和逻辑地址中的段内位移进行比较若段内位移大于段长,也会产生越界中断
页式存储管理能有效地提高内存利用率,而分段存储管理能反映程序的逻辑结构并有利于段的囲享如果将这两种存储管理方法结合起来,就形成了段页式存储管理方式在段页式系统中,作业的地址空间首先被分成若干个逻辑段每段都有自己的段号,然后再将每一段分成若干个大小固定的页对内存空间的管理仍然和分页存储管理一样,将其分成若干个和页面夶小相同的存储块对内存的分配以存储块为单位,如图3-16所示
注意:在一个进程中段表只有一个,而页表可能有多个 在进行地址变换时,首先通过段表查到页表起始地址然后通过页表找到页帧号,最后形成物悝地址如图3-18所示,进行一次访问实际需要三次访问主存这里同样可以使用快表以加快查找速度,其关键字由段号、页号组成值是对應的页帧号和保护码。