electric relaxation

…as promised. I used tbench, which is available in the Debian package archive:

$ sudo apt-get install dbench


My ‘test’ was to run a loopback tbench run with three clients. Make sure your VM isn’t doing anything intensive, then issue:

$ tbench_srv &
$ tbench 3


This will run a tbench test with three clients connected to the server, for 10 minutes with 2 minutes of warmup time. The comparison between VMI and non-VMI kernels on my machine was quite favorable: I got almost a 2X speedup when running with the VMI-enabled kernel! The numbers were 55MB/s before, and 95MB/s after.

I suspect this is some kind of pathological worst-case for the non-VMI kernel, since most benchmarks aren’t nearly this favorable. But nonetheless, I was happy with the result and so I didn’t question it too much.

More about dbench and tbench, from the manpage:

Netbench is a terrible benchmark, but it’s an “industry standard” and it’s what is used in the press to rate windows fileservers like Samba and WindowsNT. Given the requirements of running netbench (60 and 150 Windows PCs all on switched fast ethernet and a really grunty server, and some way to nurse all those machines along so they will run a very fussy benchmark suite without crashing), these programs were written to open up netbench to the masses.

Both dbench and tbench read a load description file called client.txt that was derived from a network sniffer dump of a real netbench run. client.txt is about 4MB and describes the 90 thousand operations that a netbench client does in a typical netbench run. They parse client.txt and use it to produce the same load without having to buy a huge lab.

dbench produces only the filesystem load. It does all the same IO calls that the smbd server in Samba would produce when confronted with a netbench run. It does no networking calls.

tbench produces only the TCP and process load. It does the same socket calls that smbd would do under a netbench load. It does no filesystem calls. The idea behind tbench is to eliminate smbd from the netbench test, as though the smbd code could be made infinitely fast.

This web site runs on Debian “Lenny”, in a virtual machine, powered by VMware Workstation 6.0 running on my Media Center PC at home. The primary bottleneck in this ghetto setup is definitely Comcast, given that my upstream bandwidth is only about 250-300Kbps. Nevertheless, a faster VM can still improve latency on page loads and given that the whole setup is running on a craptacular P4, I don’t exactly have CPU power to spare.

Enter VMI. If I was creating a new installation, I’d go with Ubuntu Feisty, since the Feisty kernel ships with VMI support enabled. But I didn’t want to go through the hassle of converting my existing machine, especially since apps like Wordpress don’t do a great job of separating their data in a way that would make this operation easy.

So I decided to try building a newer kernel, with VMI support enabled, for my Debian installation. This turned out to be fairly painless. I mostly followed the useful instructions I found here. Here’s the step-by-step process:

1. Power off your VM, and enable paravirtualized kernel support in the Virtual Machine Settings menu:

   

2. Get the kernel package build tools you’ll need:
   $ sudo apt-get install kernel-package ncurses-dev
   Note: It’s possible to do all of these steps without running as root, using fakeroot and sudo, but I found it much easier to just su and get it over with.
3. Download the 2.6.22-rc3 kernel package from kernel.org. VMI was actually included in 2.6.21, but the menuconfig options are missing in that release for some reason. Anyway, these instructions should apply to the final 2.6.22 release as well.
4. Extract the tarball into /usr/src:
   $ cd /usr/src && tar jxf /path/to/linux-2.6.22-rc3.tar.bz2
5. Change to /usr/src/linux-2.6.22-rc3 and issue make menuconfig.
6. The quickest and simplest thing to do here is to load your existing configuration, then modify it to enable VMI support. Select Load an Alternate Configuration File and enter the path to your existing kernel configuration, which you can find in /boot. In my case, the correct path was /boot/config-2.6.18-4-686.
7. Now it’s time to actually enable VMI support. You can find the VMI menu option under Processor Type and Features:

   



Aside: Notice in the above screenshot that I enabled the Tickless System (Dynamic Ticks) option. You can read more about dynticks here. Note that dynticks and VMI didn’t always play nice together, an issue which caused some fireworks on LKML. Nonetheless, in 2.6.22 these issues appear to have been resolved. Dynticks probably isn’t much of a win since I’m only running a single VM, but given the popularity of this blog, that VM is likely to be doing a whole lot of nothing, so maybe I’ll save a few pennies on my power bill.

8. You’re now ready to build the kernel package. Just to be safe and explicit, choose the Save to Alternate Configuration File option, then hit enter to accept the default, .config. This will save your new configuration as the active one. Now at the command prompt, you can build the kernel with the following commands:
   
$ make-kpkg clean
$ make-kpkg --revision 1.0.vmi kernel_image

   You can replace 1.0.vmi above with a revision of your choosing. However, your string must have only letters, numbers and the period character. Important: Make sure you don’t skip the make-kpkg clean step or you’ll be hit with obscure and confusing error messages.
9. The kernel compile will take a while, so go grab a cup of coffee. When it’s done, you’ll have a shiny new Debian kernel package sitting in /usr/src. In my case, the build package was:
   /usr/src/linux-image-2.6.22-rc3_1.0.vmi_i386.deb.
   Install the package:
   dpkg -i /usr/src/linux-image-2.6.22-rc3_1.0.vmi_i386.deb
10. Hopefully, the package will install cleanly. In my case, I got an error about initramfs, and the initrd image was not created. I resolved this by manually creating the matching initrd with the handy update-initramfs command:
    $ update-initramfs -k 2.6.22-rc3 -c -v
11. You’re almost there! The last step is to run update-grub to update the list of available kernels to boot. You should see your new kernel enumerated in the list printed out by update-grub.
12. Now cross your fingers, reboot, and select the new kernel. If all goes well, your VM will boot and you’ll be sitting at a login prompt in noticeably less time than with your old kernel. Just to make sure, you should see some VMI messages printed in the kernel message log:
    
$ dmesg | grep VMI
vmi: registering clock event vmi-timer. mult=11715026 shift=22
Booting paravirtualized kernel on vmi
vmi: registering clock source khz=2793080
Time: vmi-timer clocksource has been installed.


Ok, that does it. Not too hard, was it?

Next: some wildly unscientific VMI benchmarking.