Re: [PATCH v12] tolerate jitter in cpu_khz calculation to avoid TSC emulation

[Olaf Hering <olaf@aepfle.de>]

[-- Attachment #1.1: Type: text/plain, Size: 1303 bytes --]

Am Mon, 11 Mar 2019 04:02:14 -0600
schrieb "Jan Beulich" <JBeulich@suse.com>:

> > One interesting aspect is: the xenlinux based kernels report clocksource=tsc,  
> I don't think they do - iirc they are hardcoded to clocksource=xen.

For HVM they do:

 # dmesg | grep -Ei '(clock|hz)'
[    0.000000] hpet clockevent registered
[    0.000000] tsc: Detected 2000.225 MHz processor
[    0.142074] smpboot: CPU0: Intel(R) Xeon(R) CPU           E5504  @ 2.00GHz (fam: 06, model: 1a, stepping: 05)
[    0.322108] hpet0: 3 comparators, 64-bit 62.500000 MHz counter
[    0.324095] Switched to clocksource hpet
[    2.436321] tsc: Refined TSC clocksource calibration: 2000.084 MHz
[    3.437123] Switched to clocksource tsc

But PV shows just that:

 # dmesg | grep -Ei '(clock|hz)'
[    0.000000] Xen reported: 2000.084 MHz processor.
[    0.316671] Switched to clocksource xen

> > There was even that 'independent_wallclock' knob. Why is that?  
> Why is what? Are you questioning the presence of the setting in
> the XenoLinux kernels, or its absence in the pv-ops ones?

I'm just curious why HVM uses tsc, but nothing states that using ntpd would be a requirement.

However, a brief search suggests that reported "clock issues" are indeed solved by running ntp in HVM.

Olaf

[-- Attachment #1.2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel