bfin-uclinux内核的内存管理主要涉及三种算法，bootmem，buddy和slab。其中bootmem在内核启动的初期发挥作用，它将系统的可用内存以页的形式组织起来。然后Buddy算法接管这些页，将之分成不同大小的页块，这个工作完成后，bootmem退出舞台且不再出现。而slab算法则从buddy中取一些页面出来进行小对象的分配，内核的实际对象分配都是使用它来完成的。在这三种算法的配合下，内核得以高效利用内存。

　　那么，高效到底高到什么程度呢？在《The Slab Allocator: An Object-Caching Kernel Memory Allocator》这篇文章中，Jeff Bonwick对此有了非常完整的说明并给出了一些实验数据。这篇文章发表于1994年，这么多年了，内核经过无数次的修改，这篇文章中的数据是否还能适用？最近刚好在研究内存管理，就来验证一下吧！

　　虽然在VDSP下可以进行一些验证工作，但是效率偏低。况且这个算法本身应该是可以独立于内核的。怎么办？将之移植出来似乎是一个不错的办法。

　　为了尽可能少地改动内核的代码，选用一个兼容的编译器就成了很好的选择。经过考虑，决定选择如下平台：

　　AMD Sempron 2800+

　　Windows XP

　　CodeBlocks 8 IDE

　　Cygwin gcc 3.4.4

　　Mingw做为备选编译器

　　在此平台下验证通过后再到VDSP下跑得到一组内核实际运行的数据。

　　在cygwin下编译时取消开关中断和同步处理。

　　先做了个简单测试：

int main()
{
　　　 int i;
　　　 void *p;
　　　 srand(time(NULL));
　　　 start_kernel();
　　　 for(i = 0; i < 100000; i++)
　　　 {
　　　　　　　 //p = kmalloc(rand() % 1000000, GFP_KERNEL);
　　　　　　　 //kfree(p);

　　　　　　　 p = malloc(rand() % 1000000);
　　　　　　　 free(p);
　　　 }
　　　 return 0;
}

　　这段代码用于不断分配随机大小的内存块，然后释放。

　　在不启用优化的情况下，经过运行，使用slab算法进行1千万次的分配只要3.343秒，而直接使用malloc进行十万次的分配却要6.640秒，看来有很多个数量级的差距啊。

　　在启用优化的情况下（-O3），经过运行，使用slab算法进行1千万次的分配只要1.031秒，而直接使用malloc进行十万次的分配却要6.535秒，看来有很多个数量级的差距啊。

　　从这里还可以看到，GCC的优化效率还是不错的，一下提高了3倍的效率，还啥事都不要做。呵呵。

　　更多精彩，稍后继续~~~~~~~~~~~~~~~

编缉推荐阅读以下文章

• 在gcc下模拟bfin-uclinux的内存管理（2）：所需要的文件及其更改