4

So as part of a course in OS that I'm taking, I've implemented a memory allocator (just like malloc in C). The free space is stored in a linked-list.

My question in then following: How would I go about testing the various allocation strategies (e.g. first-fit, best-fit and worst-fit). Right now I'm just iterating for a predefined number of times, each time allocating a block of size 1-N byte, where N is something like 20000. Basically I allocate for some iterations then I switch it up by deallocating some of the allocated blocks. Before exiting I check the freelist and calculate the external fragmentation. I'm unsure whether this is the way to go, or is there a better apporach for doing this?

One problem with choosing random block sizes for each strategy is that one can't really compare them if the allocated block sizes differ, right? So the alternativ would be to perform the same test, only now I use the same alloc sizes and free the same blocks when testing each strategy.

Hope this wasn't to confusing :)

dandan78
  • 13,328
  • 13
  • 64
  • 78
me_L_coding
  • 169
  • 10
  • If your allocator's free() merges adjacent blocks, the number of fragments will equal the number of items on the freelist (plus or minus one) – wildplasser Dec 25 '12 at 14:29
  • @wildplasser. Thanks for replying:) I know this:) acutally i already have a working implementation that calculates the external fragmentation. I was more interested to know if the apporach i used for testing the different strategies is sufficent..or is there a better way of doing this? – me_L_coding Dec 25 '12 at 14:35
  • Maybe the most usefull measure would be to count the number of actual pages being used, and the number of effective pages, and maybe their ratio. Another measure could be the effective versus actual span of virtual addresses (max(address) - min(address)), address space is also a valuable resource. – wildplasser Dec 25 '12 at 14:40
  • @wildplasser. Nice tips indeed:) – me_L_coding Dec 25 '12 at 15:18

1 Answers1

0

Here's just an idea: You could sample data from an actual running system and then use that as your test data. Your tester would then just need to read the log file of your recorded data and replay the same alloc(), free() calls to your allocator. To achieve this in practice might be tricky, but on Linux with Glibc, they have an official way to add custom hooks to malloc, realloc and free:

http://www.gnu.org/software/libc/manual/html_node/Hooks-for-Malloc.html

So basically I imagine you could build a modified glibc with hooks that log each allocation request via malloc(), realloc() and free() calls. Run some typical programs using your log-enabled glibc and do some typical things with those programs. Try to make it representative in some way -- like run Apache if you are doing this specifically to test usage for web servers, etc. The generated logs should then be a reasonable simulation of "authentic" allocation behaviour of the system. To make the test more accurate you should probably repeat the logging process with other systems or in other scenarios, etc... to make your sampling more representative and less vulnerable to "flukes". A good allocator should maximize performance across as many real live tests as possible rather than working really good sometimes and performing miserably other times.

For rebuilding packages from Linux like Glibc, a good resource is the Linux from Scratch project, http://www.linuxfromscratch.org/ .

Brandin
  • 906
  • 11
  • 20