Simulation of bfin-uclinux memory management under GCC (1): Basic ideas

The memory management of Bfin-uclinux kernel mainly involves three kinds of algorithms, Bootmem,buddy and slab. The Bootmem, which works at the beginning of the kernel, organizes the available memory of the system as a page. The buddy algorithm then takes over the pages and divides them into blocks of different sizes, and when this completes, the Bootmem exits the stage and no longer appears. The slab algorithm takes some pages out of the buddy to allocate small objects, and the actual object allocation of the kernel is done using it. With the combination of these three algorithms, the kernel is able to utilize memory efficiently.

So, how high is efficiency in the end? In the article "the Slab Allocator:an object-caching Kernel Memory Allocator", Jeff Bonwick has a very complete description of this and gives some experimental data. This article was published in 1994, so many years, the kernel after countless changes, the data in this article can still apply? Recently just in the study of memory management, just to verify it!

Although some verification work can be done under the VDSP, the efficiency is low. Moreover, the algorithm itself should be independent of the kernel. What to do? It seems like a good idea to transplant it.

In order to change the kernel's code as little as possible, it's a good choice to choose a compatible compiler. After consideration, decided to choose the following platform:

AMD Sempron 2800+

Windows XP

Codeblocks 8 IDE

Cygwin GCC 3.4.4

MinGW as an alternative compiler

Under this platform, verify the pass and then run to the VDSP to get a set of data that the kernel actually runs.

Cancels switch interrupts and synchronizes at compile time under Cygwin.

Let's do a simple test:

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;
}

This code is used to continuously allocate random sized chunks of memory and then release.

In the case of not enabling optimization, after running, using the slab algorithm for 10 million distribution as long as 3.343 seconds, and the direct use of malloc 100,000 of the distribution is 6.64 seconds, there seems to be a lot of number of levels of difference ah.

In the case of enabling Optimization (-O3), after running, using the slab algorithm for 10 million of the allocation as long as 1.031 seconds, and the direct use of malloc 100,000 of the distribution is 6.535 seconds, there seems to be a lot of difference between the number of levels.

As you can see from here, GCC's optimization efficiency is still good, a 3 times-fold increase in efficiency, do not do anything. Oh.

More wonderful, later continue ~~~~~~~~~~~~~~~