Re: [Xen-devel] [PATCH v13] tolerate jitter in cpu_khz calculation to avoid TSC emulation

[Olaf Hering <olaf@xxxxxxxxx>]

Am Wed, 13 Mar 2019 03:18:39 -0600
schrieb "Jan Beulich" <JBeulich@xxxxxxxx>:

> I'm sorry, but I continue to object to this adjustment getting done
> both by default _and_ not in a per-guest manner. As said before,
> you can't demand guests to run NTP, and hence you can't expect
> them to get along with a few hundred kHz jump in observed TSC
> frequency. Whether the performance drop due to vTSC use is
> better or worse is a policy decision, which we should leave to the
> admin. Hence the feature needs to be off by default, and there
> needs to be at least a host-wide control to enable it; a per-guest
> control would be better. IOW I explicitly do not agree with the
> last sentence of the commit message.

So this seems the be the essential part that prevents moving forward.

Your claim is basically that "we do not know how the workload reacts
to frequency change".
My claim is basically "there is enough evidence that syncing with
external clock is required if the frequency remotely matters".

I think that conflict can not be easily solved.

One way to solve it would be a knob that injects a value into the
proposed "vtsc_tolerance_khz" variable, leave the calculation to
the host admin, and leave code in tsc_set_info basically as is.

Maybe "xl set-params" can be the way to change the value, that way
it can be changed globally at runtime if needed.

In staging the change would affect HVM and PVH. I never ran PVH,
I have to assume it behaves like HVM in this regard.


Olaf

Attachment: pgpKCkKqMYq3O.pgp
Description: Digitale Signatur von OpenPGP

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