1 引言
内存管理是操作系统的中心任务之一，其主要任务是组织内存以容纳内核和待执行程序，跟踪当前内存的使用情况，在需要时为进程分配内存，使用完毕后释放并回收内存。目前嵌入式系统中常用的内存管理策略主要有两种—静态内存分配和动态内存分配。
静态内存分配—编译或链接时将将所需内存分配好，程序运行起来所分配的内存不释放。对于实时性和可靠性要求极高的系统，不允许延迟或者分配失效，必须采用静态内存分配的方式。
动态内存分配—根据程序执行过程中所需内存的大小而动态的分配内存的策略。此方案按需分配内存，避免了静态分配中的内存浪费，灵活性比较强，给程序的实现带来了很大方便。但缺点是容易造成内存碎片，且容易造成程序响应不及时等问题。
综上所述，静态内存分配和动态内存分配各有优点，出于嵌入式系统可靠性、实时性及成本、功耗的考虑，如何在两种方案中做出平衡的选择一直是令嵌入式操作系统设计者头疼的事，一般的嵌入式操作系统都是二种方案的高效结合，µC/OS-II也不例外。除此之外，嵌入式操作系统对内存的分配还有以下几点要求：
（1）可靠性：内存分配的请求必须得到满足，如果分配失败可能会带来灾难性的后果。比如，航天飞机的嵌入式操作系统若发生内存分配失效，损失是不可估量的。
（2）快速性：嵌入式系统对实时性的保证，要求简单、快速地分配内存。
（3）高效性：嵌入式系统中内存是一种有限、昂贵的资源，内存分配要尽可能地少浪费。
µC/OS-II作为一种典型的嵌入式操作系统，其内存管理同样要满足以上三点要求，下面就来简单介绍一下µC/OS-II的内存管理策略，并分析其不足之处。
/******************************************************************************************************************************************/
原创作品，转载时请务必以超链接形式标明文章原始出处:http://blog.csdn.net/gqb_driver/article/details/17019275,作者:gqb666/******************************************************************************************************************************************/
2 µC/OS-II动态内存管理方案及不足
2.1µC/OS-II内存管理方案简介
µC/OS-II内存管理模块主要由一个数据结构体和五个函数组成：
◆ 内存控制块数据结构OS_MEM
◆ 内存分区创建函数OSMemCreate（void*addr, INT32U nblks, INT32U blksize, INT8U *err）
◆ 内存块分配函数OSMemGet（OS_MEM *pmem , INT8U *err）
◆ 内存块释放函数OSMemPut（OS_MEM *pmem , void *pblk）
◆ 内存分区状态查询函数OSMemQuery（OS_MEM*pmem, OS_MEM_DATA *p_mem_data）
◆ 内存控制块链表初始化函数OSMemInit（void）
µC/OS-II用一个内存控制块（OS_MEM）来管理内存分区。主要通过以下四步来管理：
（1） 内存控制块链表初始化函数OSMemInit（）负责创建空内存控制块结构的链表，链表长度由内核OS_CFG.H文件中定义的OS_MAX_MEM_PART宏确定。
（2） 内存块创建函数OSMemCreate（）先从空内存控制块结构链表上获取一个空的内存控制根块结构，根据用户需要内存块的大小来创建分区，一个分区中含有相同大小的内存块，各内存块也是通过链表链接起来，而不同分区中的内存块大小一般不同如图1所示的Partition# 1和Partition# 2中内存块的大小是不同的。
（3） 内存块分配函数OSMemGet（）通过从内存控制块链表中找到能够满足自己内存块需要的内存控制块，然后从这个内存控制块指向的分区链表首部得到自己需要的内存块。
（4） 内存块释放函数OSMemPut（）负责回收内存块。当应用程序不再使用某一个内存块时，必须及时把它释放，并放回到相应的内存分区中。
图1 µC/OS-II通过内存控制块管理内存
2.2µC/OS-II内存管理方案的不足之处
如前所述，µC/OS-II的内存管理方案简短精炼，仅百余行代码，5个函数就能胜任。然而考虑到第1节提到的嵌入式系统对内存管理策略的三个要求。得出µC/OS-II的内存管理策略存在以下不足之处：
（1）原µC/OS-II内存管理方案可靠性不高。因为原方案中各内存分区之间是孤立的，没有联系。一个内存分区上的内存块用完的话，不能利用其他分区上的内存块，而只是简单地报错，从而使系统可靠性大大降低。在内存块大小及需求量不确定的场合，如果经常发生内存申请得不到满足的情况，是嵌入式系统所不能容忍的。
（2）原µC/OS-II内存管理方案中内存分配不够灵活。举个例子来说，一个应用程序需要大小为1K、512B、256B三种内存块，原方案有两种解决方案，一是创建一个内存块大小为1K的内存分区，内存块数目至少为3个；二是创建三个内存分区，内存块大小分别为1K、512B、256B。方案一创建了较少分区，性能有保证，但造成内存资源的浪费；方案二虽然没有浪费内存，但却调用三次OS_MemCreate()函数，效率较低。
3 Buddy算法简介
Buddy算法是用做内存管理的经典算法，目的是为了解决内存的外碎片问题以及提高内存管理的可靠性。Buddy算法在linux内核内存管理模块得到成功地应用。
图2 Buddy算法简介
如图2 所示，buddy算法将所有空闲页框分组为10个块链表，每个块链表的每个块元素分别包含1,2,4,8,16,32,64,128,256,512个连续的页框，每个块的第一个页框的物理地址是该块大小的整数倍。例如，大小为4个页框的块，其起始地址是4*2^12(一个页框的大小为4k,4个页框的大小为4*4K,1k=1024=2的10次方，4k=2的12次方)的倍数。
假设要请求一个128个页框的块，算法先检查128个页框的链表是否有空闲块，如果没有则查256个页框的链表，有则将256个页框的块分裂两份，一份使用，一份插入128个页框的链表。如果还没有，就查512个页框的链表，有的话就分裂为128，128，256，一个128使用，剩余两个插入对应链表。如果在512还没查到，则返回出错信号。用这种方法来分配页框，由linux内核的稳定性告诉我们，其可靠性是毋庸置疑的。
回收过程相反，内核试图把大小为b的空闲伙伴合并为一个大小为2b的单独块，满足以下条件的两个块称为伙伴：1，两个块具有相同的大小，记做b；2，它们的物理地址是连续的，3，第一个块的第一个页框的物理地址是2*b*2^12的倍数，该算法迭代，如果成功合并所释放的块，会试图合并2b的块来形成更大的块。在本方案中，只要做到前两个条件就足够了。
4 µC/OS-II内存管理改进方案
由2.2的分析可知，µC/OS-II内存管理在可靠性及灵活性方面存在明显不足，以及Buddy算法在可靠性上的优势，本节就结合这两点提出一种改进方案，该方案有效解决了以上问题。
4.1改进方案思路
（1）修改内存控制块的结构OS_MEM，去掉OS_MemAddr、OS_MemNFree成员，添加一个内存块链表尾指针OSMemBlkTail，所以OS_MEM结构还含有4个成员：OSMemFreeList、OSMemBlkSize、OSMemNBlks、OSMemBlkTail。改进后的内存控制块结构如图2所示。
（2）首先初始化一个内存控制块结构数组structOS_MEM []，其下标是内存块规模1的对数，引入结构数组的目的是在申请内存块时能够快速定位，起到索引的作用。而内存块的实际大小为内存块规模与内存块粒度[1]的乘积。然后将内存块按内存块规模从小到大挂到不同结构数组指向的链表上，并且保证初始化后同一链表上的内存块地址不连续。在申请内存块通过内存控制结构数组的下标快速定位到内存块链表，查看内存块控制结构字段中OSMemFreeList成员指针是否为空，若不为空，则从表头取一个内存块，并返回该内存块的地址；否则向后搜索数组，看否有空闲内存块，若有则将该内存块一分为二，低地址的那块分配给申请者，高地址的那块则挂到前一个结构数组的表头，以备其他申请者申请。同样释放内存块时也是通过结构数组快速定位到具体结构数组，然后检查该结构数组内存块链表中是否有和要释放的内存块地址连续的内存块，若有则合并两内存块并挂到后一个结构数组并作地址是否连续检查，直至没有为止；若无则将该内存块挂到该内存块链表的表尾。改进后的内存管理组织结构如图2所示。具体实现过程如下：
主要改进以下几个功能函数：
① voidOS_MemInit(void)
② OS_MEM *OSMemCreate(void *addr, INT32U nblks, INT32U granularity , INT8U *err)
//其中第一个参数为所创建内存空间的起始地址，第二个参数是指每个结构体数组链表在创建完成后所链接的内存块数，第三个为内存块的粒度
③ void *OSMemGet( OS_MEM *pmem , INT32 size,INT8U *err)
④ INT8U OSMemPut( OS_MEM *pmem,INT32 size )
4.2具体改进措施
（1） 改进函数OS_MemInit(void)，此函数原来是初始化空闲内存控制块链表，改进后此函数用于初始化OS_MEM结构数组即可，根据OS_CFG.H文件中宏OS_MAX_MEM_PART来决定数组元素个数。
（2） 改进函数OSMemCreate(void*addr, INT32U nblks, INT32U granularity, INT8U *err)，根据Buddy的规则横向创建内存块，每创建一个内存块就链到相应的结构体数组上，如图2的CreateDirection所示，这样能保证每个结构数组上的相同大小的内存块地址不连续，从而避免了所有内存块合并的现象。创建出来的内存块组织结构如图2所示。
（3） 改进函数OSMemGet(INT32Usize, INT32U granularity,INT8U *err)，因为结构体数组名是在OS_CFG.H文件中宏定义的，所以本函数的参数只包括需求的内存块大小及内存块粒度即可。用内存块大小除以内存块粒度，首先判断所得值是否为2的指数次，若是直接取对数即得结构数组的下标；若不是则取对数后向上取整，得到指定数组元素后若有内存块取下一内存块然后指针下移，若无内存块则继续搜索下一个结构数组，若该数组有空闲内存块则取将其平分为两块，一块分配出去，一块挂到前面结构数组链表。这样一直搜索到最后一个结构数组，若一直无内存块，则报错返回。
（4）改进函数OSMemPut(INT32Usize, INT32U granularity)，如何取得结构数组下标值同OSMemGet()函数，在找到所要回收的结构数组后，判断该数组内存块链表上是否有与要回收的内存块连续的地址，若有合并且挂到下一内存块结构数组内存块链表，这样一直到最后一个结构数组，目的是为了保证有更大的内存块可满足应用程序的申请，提高了内存管理的可靠性。
在改进以上函数的基础上，还可以在申请内存块之前有选择地使用OSMemQuery()查询内存中是否有满足需要的内存块，如果没有则作好的相应的规避措施，进一步提高内存管理的可靠性，使系统更稳定。
改进方案中内存管理组织结构如图3所示：
图3 改进方案中的内存管理组织结构
5 结果及性能分析
针对改进前后µC/OS-II内存管理策略的特点，设计一组具有代表性的测试用例来分析µC/OS-II系统在改进前后内存管理的可靠性和灵活性。实验环境为ARMDevelop Suit V1. 2及三星公司S3C2440微控制器，由于S3C2440片内包含MMU模块，所以需要将协处理器CP15的C1寄存器0位置0以禁用MMU功能。
假设两种方案内存初始化都创建了5个分区，每个分区中所含内存块为10个，且这5个内存分区中的内存块大小依次为16B,32B,64B,128B,256B。原方案创建分区时要调用5次OSMemCreate()函数，而改进方案只需调用一次。下表是申请内存块大小与两种方案可以满足的次数之间的关系。
| 申请内存块大小 | 原方案可满足次数 | 新方案可满足次数 |
| 16B | 10 | 310 |
| 32B | 10 | 150 |
| 64B | 10 | 70 |
| 128B | 10 | 30 |
| 256B | 10 | 10 |
表1 申请内存块大小与两种方案可以满足的次数比较
图4两种方案可满足次数对比曲线
由上表的数据及图4的对比曲线可看出，改进方案与原方案在可用内存完全相同的情况下，使内存的利用率大大提高。因为可靠性与可满足次数正相关，而可满足次数与曲线与坐标轴围成的面积成正比，所以该面积与可靠性正相关。新方案曲线所围图形面积为12960，而原方案曲线所围成的图形面积为2400。所以新方案的可靠性将比原来方案提高大约4倍，而且申请内存块越小，可满足次数越性，提高内存分配的灵活性。
结 语
本文的创新之处在于针对µC/OS-II在内存管理可靠性不高，内存块分配不够灵活的特点，借鉴Buddy算法思想，对其进行改进，形成了一种基于Buddy算法思想，高可靠性的内存管理策略。实验表明，新方案一次创建内存区，即可满足内存块大小需求不均匀的场合。既提高内存分配的灵活性，避免了大量内碎片的产生，又增强了内存分配的可靠性。因此，新方案在可靠性要求高的嵌入式系统中可以得到更好的应用。
441
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
