Day 2: Conference: Memtest: finding holes in the VM system

Julian Quintela explained to us to how his memtest programs came to be and what they check


Julian initially had problems with crashes while working on his PhD but there were difficult to reproduce so he ended up writing some test programs and gathering small test programs from other people, to produce one suite of programs which would hopefully test everything.

mmap001 creates a file of the size of the physical memory and writes to that file sequentially and removes it. Initially this was causing system loads of 15 and more when run in a loop.
It showed a problem where all the pages would get dirty and the system would flush all the blocks sequentially after that, locking the system in the meantime.
This problem was fixed after it was reported.

mmap002 allocates does a similar test by allocating twice the size of the memory. It showed that the system started to swap too late and the memory hog process would be advantaged wrt to other processes when it came to allocating more memory.

mmap003 hasn't been released yet, but it does an mmap of a big file in very small chunks and do random mprotects and access patterns. This also caused the system to become very unresponsive

ipc001 was written by Christopher Roland, it stresses System V shared memory as it's not used very much and it's not that much tested.

misc001 was written by Arjan van de Ven and does mallocs, memsets and frees for 1/3 of the memory. Meanwhile a second process does mmaps for another 3rd of the memory and writes to it. A 3rd thread does fwrites to random positions in a file that's half the size of the ram.

By gathering those programs, Julian reached his goal to build a set of programs that are useful when doing bug reporting on system responsiveness as you can now just quote which program you used and what behavior you got.

[library] Picture library [back] Back to Main Page [next] Next page

[ms free site] Email
Link to Home Page

2001/01/28 (13:26): Version 1.0