方案的不足之处 - Buddy算法的μC/OSII高可靠内存管理方案

2.2 μC/OSII内存管理方案的不足之处

　　如前所述，μC/OSII的内存管理方案简短精炼，仅百余行代码，5个函数就能胜任。然而考虑到第1节提到的嵌入式系统对内存管理策略的3个要求，μC/OSII的内存管理策略存在以下不足之处：

　　① 原μC/OSII内存管理方案可靠性不高。因为原方案中各内存分区之间是孤立的，没有联系。一个内存分区上的内存块用完时，不能利用其他分区上的内存块，而只是简单地报错，从而使系统可靠性大大降低。在内存块大小及需求量不确定的场合，如果经常发生内存申请得不到满足的情况，是嵌入式系统所不能容忍的。

　　② 原μC/OSII内存管理方案中内存分配不够灵活。举个例子来说，一个应用程序需要大小为1 KB、512 B、256 B三种内存块，原方案有两种解决方案，一是创建一个内存块大小为1 KB的内存分区，内存块数目至少为3个;二是创建3个内存分区，内存块大小分别为1 KB、512 B、256 B。方案一创建了较少分区，性能有保证，但造成内存资源的浪费;方案二虽然没有浪费内存，但却调用3次OS_MemCreate()函数，效率较低。

　　3 Buddy算法简介

　　Buddy算法是内存管理的经典算法，目的是为了解决内存的外碎片问题，以及提高内存管理的可靠性。Buddy算法在Linux内核内存管理模块得到成功的应用。

　　如图2 所示，Buddy算法将所有空闲页框分组为10个块链表，每个块链表的每个块元素分别包含1、2、4、8、16、32、64、128、256、512个连续的页框，每个块的第一个页框的物理地址是该块大小的整数倍。例如，大小为4个页框的块，其起始地址是4×212(一个页框的大小为4K,4个页框的大小为4×4K,1K=1024=210，4K=212)的倍数。

　　

 

　　图2 Buddy算法简介

　　假设要请求一个128个页框的块，算法先检查128个页框的链表是否有空闲块，如果没有则查256个页框的链表，有则将256个页框的块分裂为两份，一份使用，一份插入128个页框的链表。如果还没有，就查512个页框的链表，有的话就分裂为128、128、256，一个128使用，剩余两个插入对应链表。如果在512还没查到，则返回出错信号。用这种方法来分配页框，由Linux内核的稳定性可知其可靠性。

　　回收过程相反，内核试图把大小为b的空闲伙伴合并为一个大小为2b的单独块，满足以下条件的两个块称为伙伴： 两个块具有相同的大小，记做b;它们的物理地址是连续的;第一个块的第一个页框的物理地址是2b×212的倍数。该算法迭代，如果成功合并所释放的块，会试图合并2b的块来形成更大的块。在本方案中，只要满足前两个条件就足够了。

　　4 μC/OSII内存管理改进方案

　　4.1 改进方案思路

　　① 修改内存控制块的结构OS_MEM，去掉OS_MemAddr、OS_MemNFree成员，添加一个内存块链表尾指针OSMemBlkTail，所以OS_MEM结构还含有4个成员：OSMemFreeList、OSMemBlkSize、OSMemNBlks、OSMemBlkTail。改进后的内存控制块结构如图3所示。

　　

 

　　图3 改进方案中的内存管理组织结构

　　② 首先初始化一个内存控制块结构数组struct OS_MEM []，其下标是内存块规模的对数，引入结构数组的目的是在申请内存块时能够快速定位，起到索引的作用。而内存块的实际大小为内存块规模与内存块粒度的乘积。然后将内存块按内存块规模从小到大挂到不同结构数组指向的链表上，并且保证初始化后同一链表上的内存块地址不连续。在申请内存块通过内存控制结构数组的下标快速定位到内存块链表，查看内存块控制结构字段中OSMemFreeList成员指针是否为空。若不为空，则从表头取一个内存块，并返回该内存块的地址;否则向后搜索数组，看是否有空闲内存块。若有则将该内存块一分为二，低地址的那块分配给申请者，高地址的那块则挂到前一个结构数组的表头，以备其他申请者申请。同样，释放内存块时也是通过结构数组快速定位到具体结构数组，然后检查该结构数组内存块链表中是否有和要释放的内存块地址连续的内存块。若有，则合并两内存块并挂到后一个结构数组，并检查地址是否连续，直至没有为止;若无，则将该内存块挂到该内存块链表的表尾。改进后的内存管理组织结构如图3所示。