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>:

> > +    if ( tmp >= VTSC_MEASUREMENT_INACCURACY_RANGE_KHZ )
> > +        tmp -= VTSC_MEASUREMENT_INACCURACY_RANGE_KHZ;  
> The discontinuity is still there, and so far you've failed to explain
> why a discontinuity is what you want here.

I think this is part of the commit message, there is an entire paragraph
for it. Perhaps the word "jitter" needs to be replaced by something else.

> > +            khz_diff = ABS(((long)cpu_khz - gtsc_khz));  
> This could easily be the initializer of the variable. And there's one
> too many pair of parentheses.

I will look into that part.

> 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.

This per-domU knob exists already: tsc_mode=always_emulate
IF a workload expects such behavior, the host admin can enable it.

Also I explained several times that the speed in which TSC advances is
kind of "opqaue" (if that is the correct english term), not only due to the
unavoidable inaccuracy. IF a workload on bare-metal or virtualized needs
to know a more accurate time, it needs an external clocksource. Without
such source the speed will remain inaccurate before and after this change.


Also: anyone else with an opinion on this change? Cant be a Jan-One-Men-Show...

Olaf

Attachment: pgpTRfMVShMOc.pgp
Description: Digitale Signatur von OpenPGP

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