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倍的效率，还啥事都不要做。呵呵。
更多精彩，稍后继续~~~~~~~~~~~~~~~