diff options
author | Keir Fraser <keir.fraser@citrix.com> | 2009-12-01 13:36:22 +0000 |
---|---|---|
committer | Keir Fraser <keir.fraser@citrix.com> | 2009-12-01 13:36:22 +0000 |
commit | d1956b62b07379b2b77e9aee51bbdfc6e7b7c118 (patch) | |
tree | 240156035c36e6ab22475c1323c543907e446173 /tools/xenstat | |
parent | cfbf78694e29405973b6962cd97e3372b2097ba6 (diff) | |
download | xen-d1956b62b07379b2b77e9aee51bbdfc6e7b7c118.tar.gz xen-d1956b62b07379b2b77e9aee51bbdfc6e7b7c118.tar.bz2 xen-d1956b62b07379b2b77e9aee51bbdfc6e7b7c118.zip |
Report hardware tsc frequency even for emulated tsc
I was starting some documentation for tsc_mode and
realized this discussion was never resolved. Currently
when TSC is emulated the pvclock algorithm reports
to a PV OS Xen's system clock hz rate (1GHz). Linux
at boottime samples the TSC rate and shows it in
dmesg and the rate is also shown in the "cpu MHz"
field in /proc/cpuinfo. So when TSC is emulated,
it appears that the processor MHz is 1000.0, which
is likely to be confusing to many Xen users.
This patch changes the reported hz rate to the
hz rate of the initial machine on which the guest
is booted and retains that reported hz rate across
save/restore/migration.
Jeremy has pointed out that reporting 1000.0 MHz is
useful because it shows that TSC is being emulated.
However, with the new tsc_mode default where
a guest may start with native TSC and switch to
emulated TSC after migration, users are likely to
get even more confused. And "xm debug-key s"
reveals not only whether TSC is being emulated but
also the frequency so is more descriptive anyway.
Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
Diffstat (limited to 'tools/xenstat')
0 files changed, 0 insertions, 0 deletions