砖1 伙伴算法

家里煤矿搬迁，要搬了，腰包了，村子里都在盖二层，于是搬砖。

北京房价太贵，要买房，只能现在开始一块一块，慢慢搬砖，少发点牢骚，多搬点砖。

每天记录自己学到的，加油，搬砖工。

一、伙伴算法

  1.伙伴系统

Linux内核中采用了一种同时适用于32位和64位系统的内存分页模型，对于32位系统来说，两级页表足够用了，而在x86_64系统中，用到了四级页表，页全局目录，页上级目录，页中间级目录，页表。

每个页表项指向一个页框，在Linux中采用4KB大小的页框作为标准的内存分配单元。

  2.基于伙伴算法的内存分配

Linux中采用伙伴系统解决外部碎片。

伙伴系统的基础是11个连续页框链表，第一个链表上只存储所有空闲的1个页框，第二个链表上只储存所有空闲的2个连续页框，以此类推。这11个链表将不同大小的连续内存块链在不同的链表上，这首先节省了遍历一个很长的链表的时间，可是使我们直奔最符合需求的连续内存。

把所有的空闲页框分组为11个块链表，每个块链表分别包含大小为1, 2, 4, 8, 16, 32, 64, 128, 256，512和1024 个连续的页框。对1024 个页框的最大请求对应着4MB 大小的连续RAM块。每个块的第一个页框的物理地址是该块大小的整数倍。例如，大小为16 个页框的块，其起始地址是16 × 212（212 ＝ 4096，这是一个常规页的大小）的倍数。

工作过程：

假设要请求一个256 个页框的块（即1MB）。算法先在256 个页框的链表中检查是否有一个空闲块。如果没有这样的块，算法会查找下一个更大的页块，也就是，在512 个页框的链表中找一个空闲块。如果存在这样的块，内核就把256 的页框分成两等份，一半用作满足请求，另一半插入到256 个页框的链表中。如果在512 个页框的块链表中也没找到空闲块，就继续找更大的块 —— 1024个页框的块。如果这样的块存在，内核把1024个页框块的256 个页框用作请求，然后从剩余的768 个页框中拿512个插入到512个页框的链表中，再把最后的256个插入到256个页框的链表中。如果1024个页框的链表还是空的，算法就放弃并发出错信号。

  3。基于伙伴算法的内存释放

内存的释放是分配的逆过程，也可以看做是伙伴的合并。当释放一个块时，先在其对应的free_area链表中查找是否有伙伴存在，如果没有伙伴块，直接将要释放的块插入链表头；如果有，则将其从链表下摘下，合并成一个大块，然后继续查找在合并后的块在更大一级链表中是否有伙伴存在，直至不能合并或者已经合并至最大的块2^10为止。

内核试图把大小为b的一对空闲伙伴块合并为一个大小为2b的单独块。（页框块在释放时，会主动将两个连续的页框块合并为一个较大的页框块）

满足以下条件的两个块称为伙伴：
• 两个块具有相同的大小，记作b。
• 它们的物理地址是连续的。
• 第一块的第一个页框的物理地址是2×b×212的倍数。

  4.伙伴位图

伙伴算法通过位图进行操作，用一位描述相邻的两块（第0块和第1块是伙伴，第2块和第3块是伙伴，但是第1块和第2块不是伙伴）的状态。这个位码叫伙伴位码。

为0的时候：说明这两块都为空闲

为1的时候：说明这两块有一块是忙（两块都忙是属于1状态吗？）

注意：这里的块就是本级的单位块。假设现在所属的组是64页，那它的伙伴块就是64页。即两个连续的64页——128页需要一个bit。

  5.伙伴算法的不足

a。合并的要求太过严格：只能是满足伙伴关系的块。比如第1,2块就不能合并。

b。碎片问题：如何内存管理的算法都存在这个问题，一个连续的内存中仅仅一个页面被占用，导致这整个内存区都不具备合并的条件。

c。算法中的浪费现象：伙伴算法是按2的幂次方分配内存区的，当需要257（2^8+1）个页面时，不得不申请2^9的页面。于是就有255个页面被浪费掉了。

d。算法的效率问题：伙伴算法涉及了比较多的计算还有链表和位图的操作，开销还是比较大的，如果每次2^n大小的伙伴块就会合并到2^(n+1)的链表队列中，那么2^n大小链表中的块就会因为合并操作而减少，但系统随后立即有可能又有对该大小块的需求，为此必须再从2^(n+1)大小的链表中拆分，这样的合并又立即拆分的过程是无效率的。

参考了很多，学习了。明天接着来