I began this project simply by getting up to speed with what was going on: installing Ubuntu and Xen, setting up dom0 and various domUs, reading papers about scheduling and distributed computing, etc. At about this point, I began writing code. The first piece of code was create-xen-template.sh, which automates creating file-based domUs based on some “template”; the template is a bare-bones (or not) installation of some operating system into a file image, which will form the basis of created domUs. The script creates a default configuration file and copies the template disk image and swap image; it then mounts the disk image, and customizes the necessary files (/etc/hostname, for instance; it’s mostly replacing occurrences of the template’s name with the new domU’s name, as well as assigning it a unique local IP address). Then networking is set up: it’s added to dom0’s /etc/hosts as “name.xen”, and we set up key-based SSH access. This makes creating domUs very straightforward.
The bulk of my coding since then has been running tests to see how Xen behaves. Using xm sched-credit, it is possible to fix the percentage of a CPU that a domU gets (integers only); this allows us to test what the effects are of restricting or increasing CPU on different activities. The first tests I ran simply adjusted the percentage of CPU allocated to 1–3 different domUs, and then saw how high they could count in 30 seconds when given fixed slices of the CPU. The behaviour was pretty much perfect: the graphs were perfectly linear, even when three domUs were running with different weights.
Each instance of this test was performed by xen-test.c (which was designed to be extensible and hasn’t really been extended), and various wrapper shell scripts automated running this: xen-test.sh, to run one domU (like xen-test.c, un-extended but extensible); xen-cpu-test-multi.sh, to run multiple domUs with equal weights; xen-cpu-test-multi-uneven.sh, to run multiple domUs with unequal weights; and uneven-trials.sh to run one round of trials. The python scripts make-plotter.py, make-cpu-plotter.py, and make-plotter-uneven.py produced gnuplot scripts which, when run, would produce graphs of the data.
The next round of tests will be on IO-bound processes. This code is in xen-diskio-test.c, and is driven by xen-diskio-test.sh and diskio-trials.sh (make-diskio-plotter.py only worked for the first round of data). It was straightforward to obtain the data in the simple case of freading/fwriteing large blocks of data and time()ing this. However, at the time of this writing, I am encountering a number of difficulties running tests with all five independent variables (iterations, block size, number of blocks, sleep time, and busy-wait time), including (most recently) strange spikes in the amount of time taken to write data (e.g., on a preliminary testing run, getting values of 318.969164, 8.008789, 22.984651, 6.013268, and 5.996106 seconds running the same test 5 different times). Although at first my suspicion was that the new rdtsc() method of timing was introducing these errors, while sitting in front of the computer, it seems that it is literally taking this long to run. Once this problem is solved, however, I will be able to get data on how IO-bound processes behave with limited CPU, which is the current goal.