伙伴系统的概述

最新推荐文章于 2022-04-13 15:51:35 发布

melon_eater

最新推荐文章于 2022-04-13 15:51:35 发布

阅读量368

点赞数

分类专栏： linux 文章标签： linux kernel 内存管理伙伴系统内核

linux 专栏收录该内容

29 篇文章

订阅专栏

转载出处：http://blog.csdn.net/vanbreaker/article/details/7605367

伙伴系统的概述

Linux内核内存管理的一项重要工作就是如何在频繁申请释放内存的情况下，避免碎片的产生。Linux采用伙伴系统解决外部碎片的问题，采用slab解决内部碎片的问题，在这里我们先讨论外部碎片问题。避免外部碎片的方法有两种：一种是之前介绍过的利用非连续内存的分配；另外一种则是用一种有效的方法来监视内存，保证在内核只要申请一小块内存的情况下，不会从大块的连续空闲内存中截取一段过来，从而保证了大块内存的连续性和完整性。显然，前者不能成为解决问题的普遍方法，一来用来映射非连续内存线性地址空间有限，二来每次映射都要改写内核的页表，进而就要刷新TLB，这使得分配的速度大打折扣，这对于要频繁申请内存的内核显然是无法忍受的。因此Linux采用后者来解决外部碎片的问题，也就是著名的伙伴系统。

什么是伙伴系统？

伙伴系统的宗旨就是用最小的内存块来满足内核的对于内存的请求。在最初，只有一个块，也就是整个内存，假如为1M大小，而允许的最小块为64K，那么当我们申请一块200K大小的内存时，就要先将1M的块分裂成两等分，各为512K，这两分之间的关系就称为伙伴，然后再将第一个512K的内存块分裂成两等分，各位256K，将第一个256K的内存块分配给内存，这样就是一个分配的过程。下面我们结合示意图来了解伙伴系统分配和回收内存块的过程。

这里写图片描述

1 初始化时，系统拥有1M的连续内存，允许的最小的内存块为64K，图中白色的部分为空闲的内存块，着色的代表分配出去了得内存块。
2 程序A申请一块大小为34K的内存，对应的order为0，即2^0=1个最小内存块
2.1 系统中不存在order 0(64K)的内存块，因此order 4(1M)的内存块分裂成两个order 3的内存块(512K)
2.2 仍然没有order 0的内存块，因此order 3的内存块分裂成两个order 2的内存块(256K)
2.3 仍然没有order 0的内存块，因此order 2的内存块分裂成两个order 1的内存块(128K)
2.4 仍然没有order 0的内存块，因此order 1的内存块分裂成两个order 0的内存块(64K)
2.5 找到了order 0的内存块，将其中的一个分配给程序A，现在伙伴系统的内存为一个order 0的内存块，一个order
1的内存块，一个order 2的内存块以及一个order 3的内存块
3 程序B申请一块大小为66K的内存，对应的order为1，即2^1=2个最小内存块，由于系统中正好存在一个order 1的内
存块，所以直接用来分配
4 程序C申请一块大小为35K的内存，对应的order为0，同样由于系统中正好存在一个order 0的内存块，直接用来分
配
5 程序D申请一块大小为67K的内存，对应的order为1
5.1 系统中不存在order 1的内存块，于是将order 2的内存块分裂成两块order 1的内存块
5.2 找到order 1的内存块，进行分配
6 程序B释放了它申请的内存，即一个order 1的内存块
7 程序D释放了它申请的内存
7.1 一个order 1的内存块回收到内存当中
7.2由于该内存块的伙伴也是空闲的，因此两个order 1的内存块合并成一个order 2的内存块
8 程序A释放了它申请的内存，即一个order 0的内存块
9 程序C释放了它申请的内存
9.1 一个order 0的内存块被释放
9.2 两个order 0伙伴块都是空闲的，进行合并，生成一个order 1的内存块m
9.3 两个order 1伙伴块都是空闲的，进行合并，生成一个order 2的内存块
9.4 两个order 2伙伴块都是空闲的，进行合并，生成一个order 3的内存块
9.5 两个order 3伙伴块都是空闲的，进行合并，生成一个order 4的内存块

相关的数据结构

 在前面的文章中已经简单的介绍过struct zone这个结构，对于每个管理区都有自己的struct zone，而struct zone中的struct free_area则是用来描述该管理区伙伴系统的空闲内存块的

struct zone {  
    ...  
         ...      
    struct free_area    free_area[MAX_ORDER];  
    ...  
    ...  
}

struct free_area {  
    struct list_head    free_list[MIGRATE_TYPES];  
    unsigned long       nr_free;  
};

free_area共有MAX_ORDER个元素，其中第order个元素记录了2^order的空闲块，这些空闲块在free_list中以双向链表的形式组织起来，对于同等大小的空闲块，其类型不同，将组织在不同的free_list中，nr_free记录了该free_area中总共的空闲内存块的数量。MAX_ORDER的默认值为11，这意味着最大内存块的大小为2^10=1024个页框。对于同等大小的内存块，每个内存块的起始页框用于链表的节点进行相连，这些节点对应的着struct page中的lru域

struct page {  

    ...  
    ...  
    struct list_head lru;       /* Pageout list, eg. active_list 
                     * protected by zone->lru_lock ! 
                     */  
    ...  
}

连接示意图如下：
这里写图片描述
在2.6.24之前的内核版本中，free_area结构中只有一个free_list数组，而从2.6.24开始，free_area结构中存有MIGRATE_TYPES个free_list,这些数组是根据页框的移动性来划分的，为什么要进行这样的划分呢?实际上也是为了减少碎片而提出的，我们考虑下面的情况：
这里写图片描述
图中一共有32个页，只分配出了4个页框，但是能够分配的最大连续内存也只有8个页框(因为伙伴系统分配出去的内存必须是2的整数次幂个页框)，内核解决这种问题的办法就是将不同类型的页进行分组。分配出去的页面可分为三种类型：
1.不可移动页(Non-movable pages)：这类页在内存当中有固定的位置，不能移动。内核的核心分配的内存大多属于这种类型
2.可回收页(Reclaimable pages)：这类页不能直接移动，但可以删除，其内容页可以从其他地方重新生成，例如，映射自文件的数据属于这种类型，针对这种页，内核有专门的页面回收处理
3.可移动页:这类页可以随意移动，用户空间应用程序所用到的页属于该类别。它们通过页表来映射，如果他们复制到新的位置，页表项也会相应的更新，应用程序不会注意到任何改变。
假如上图中大部分页都是可移动页，而分配出去的四个页都是不可移动页，由于不可移动页插在了其他类型页的中间，就导致了无法从原本空闲的连续内存区中分配较大的内存块。考虑下图的情况:
这里写图片描述
将可回收页和不可移动页分开，这样虽然在不可移动页的区域当中无法分配大块的连续内存，但是可回收页的区域却没有受其影响，可以分配大块的连续内存。
内核对于迁移类型的定义如下:

#define MIGRATE_UNMOVABLE     0  
#define MIGRATE_RECLAIMABLE   1  
#define MIGRATE_MOVABLE       2  
#define MIGRATE_PCPTYPES      3 /* the number of types on the pcp lists */  
#define MIGRATE_RESERVE       3  
#define MIGRATE_ISOLATE       4 /* can't allocate from here */  
#define MIGRATE_TYPES         5

前三种类型已经介绍过
MIGRATE_PCPTYPES是per_cpu_pageset，即用来表示每CPU页框高速缓存的数据结构中的链表的迁移类型数目
MIGRATE_RESERVE是在前三种的列表中都没用可满足分配的内存块时，就可以从MIGRATE_RESERVE分配
MIGRATE_ISOLATE用于跨越NUMA节点移动物理内存页，在大型系统上，它有益于将物理内存页移动到接近于是用该页最频繁地CPU
MIGRATE_TYPES表示迁移类型的数目
当一个指定的迁移类型所对应的链表中没有空闲块时，将会按以下定义的顺序到其他迁移类型的链表中寻找

static int fallbacks[MIGRATE_TYPES][MIGRATE_TYPES-1] = {  
    [MIGRATE_UNMOVABLE]   = { MIGRATE_RECLAIMABLE, MIGRATE_MOVABLE,   MIGRATE_RESERVE },  
    [MIGRATE_RECLAIMABLE] = { MIGRATE_UNMOVABLE,   MIGRATE_MOVABLE,   MIGRATE_RESERVE },  
    [MIGRATE_MOVABLE]     = { MIGRATE_RECLAIMABLE, MIGRATE_UNMOVABLE, MIGRATE_RESERVE },  
    [MIGRATE_RESERVE]     = { MIGRATE_RESERVE,     MIGRATE_RESERVE,   MIGRATE_RESERVE }, /* Never used */  
};