Am Wed, 13 Mar 2019 03:18:39 -0600 schrieb "Jan Beulich" <[email protected]>:
> 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
pgpJ4RXdl0NFx.pgp
Description: Digitale Signatur von OpenPGP
_______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
