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
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
Experiments testing for proper VM time accounting
The experiments were done on a Linux 3.2 kernel on a dual-core Core2
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
Back to my projects page