OS: Centos 6.2
KVM version: qemu-kvm-tools-0.12.1.2-2.209.el6_2.4.x86_64
qemu-kvm-0.12.1.2-2.209.el6_2.4.x86_64
uname -a:
Linux myhost 2.6.32-220.7.1.el6.x86_64 #1 SMP Wed Mar 7 00:52:02 GMT 2012
x86_64 x86_64 x86_64 GNU/Linux
Hi,
I have been performance testing a time tracing utiliity for a Java
enterprise application at work. The idea is that we measure time for
different parts of our application and build time trees for this
information. The time tree can be viewed and analysed in case of problems.
It is also automatically output in case a certain operation is taking
longer than a threshold.
As part of these tests we found that it matters a lot what type of
clocksource is used. In particular, with hpet and acpi_pm the execution is
very slow (700ns per call (similar results using clock_gettime() in a C
program). In addition, hpet and acpi_pm sycnrhonize the application. This
is of course a disaster for server applications that tend to query the
current time quite a lot.
What works quite well is the tsc clocksource. In that case, the time drops
to about 38ns on one of our systems and we can prove that there is no
synchronization anymore which is good.
When running inside a KVM VM the default clock source is kvm-clock. This
clock takes about 160ns per call and also does not synchronise the
application. However, using the tsc clock source delivers similar
performance on the virtual machine as on the host.
I now have the following questions:
* can the performance of kvm-clock be optimized further to be (almost)
identical to that of the host's clock source?
* what are the consequences of using the tsc clock in combination with
NTPD? Will this result in system instability or larger than usual clock
skew?
Cheers
Erik
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
