Re: [PATCH v10] new config option vtsc_tolerance_khz to avoid TSC emulation

[Olaf Hering <olaf@aepfle.de>]

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

On Fri, Dec 07, Olaf Hering wrote:

> [ the math added to xen-tscmode.7 suggests that a domU should see a time
>   drift, which ntpd corrects. But the actual correction reported in
>   ntp.drift is entirely different than the one calculated in the
>   example. To me it is unclear why the example is wrong, more research
>   must be done. I'm sending this out just to get feedback about how
>   exactly the per-host knob must be implemented. ]
> 
> Add a knob to control when vTSC emulation will be activated for a domU
> with tsc_mode=default. Without such option each TSC access from domU
> will be emulated, which causes a significant perfomance drop for
> workloads that make use of rdtsc.

I wonder why this needs to be a config option at all.


I think that if a domU uses TSC as clocksoure it also must run NTP in
some way to avoid the potential drift what will most likely happen,
independent of any migration. And if it must do that, NTP will handle a
drift up to 500 PPM. This means 500us. But if a domU is moved from a
2.3GHz host to a 2.4GHz host the expected drift is much larger. The
clock will run slower, the amount of ticks representing a second happen
within a timespan of 0.958333 seonds. Adding the drift to that number
means an NTPd could correct up to 0.958833 seconds. This is out of
bounds either way.

If Xen already bases its decision to emulate TSC on bogus numbers,
shouldnt it automatically allow some tolerance for tsc_mode=default?
Xen itself can not know if the estimated value in cpu_khz is at the edge
or in the middle of the range of possible freqencies. If we assume the
total range is 200 KHz, and up to 500 PPM can be corrected, a possible
default tolerance would be like: [insert math here]


So I think the suggested vtsc_tolerance_khz should in fact add a local
static vtsc_tolerance_khz into xen/arch/x86/time.c, and tsc_set_info
should base the decision on this variable like it is already done in the
suggested patch. No admin tuning of this value is required IMO.

Olaf

[-- Attachment #1.2: signature.asc --]
[-- 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