aboutsummaryrefslogtreecommitdiffstats
path: root/tools/xenstat
diff options
context:
space:
mode:
authorKeir Fraser <keir.fraser@citrix.com>2009-12-01 13:36:22 +0000
committerKeir Fraser <keir.fraser@citrix.com>2009-12-01 13:36:22 +0000
commitd1956b62b07379b2b77e9aee51bbdfc6e7b7c118 (patch)
tree240156035c36e6ab22475c1323c543907e446173 /tools/xenstat
parentcfbf78694e29405973b6962cd97e3372b2097ba6 (diff)
downloadxen-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