PAPI-V results

These results investigate whether PAPI_get_virt_usec() reports useful information in a virtualized guest.

What is needed to properly report time on PAPI in virtualized environments is per-process "steal-time" accounting. Steal time is time stolen from your running guest by the hypervisor, usually due to the CPU you are running on being busy with other things.

Linux per-processor steal time accounting has been proposed and rejected (see this linux-kernel thread: [RFC][PATCH v2 4/7] taskstats: Add per task steal time accounting

We can get per-cpu and overall system steal-time, but this doesn't completely solve the PAPI case where we want to know how much CPU time our particular process/thread got. It is "good enough" in cases where kernel overhead is minimal and we are the only job running on a virtual system.

Experiments testing for proper VM time accounting

The experiments were done on a Linux 3.2 kernel on a dual-core Core2 MacBookPro laptop.

For the KVM results, the KVM guest was running a 2.6.32 kernel internally.

The test is a 400x400 Naive Matrix-matrix multiplication. The CPU-hogging applications are infinite loops of 100x100 Naive Matrix-matrix multiplications in a separate process (or VM).

On actual hardware, the virtual timer results are as expected. Despite the overall CPU load going up and wallclock time increaing, the virtual time stays roughly the same.

On the KVM case, unfortunately the virtual timer does not report the "actual" amount of time needed to run the benchmark. Instead it tracks the "real" time. This is somewhat expected; as far as the program knows it has used all of the available guest OS's time. This does mean though that the measurement is affected by other guests running on the system. We need to do something extra to support proper time accounting.

We have also run this experiment on VMware Workstation and see similar results.

Back to my projects page