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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.03.19 at 11:23, <olaf@xxxxxxxxx> wrote:
> 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.

I don't think the commit message explains the anomaly.

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

But this affects a guest even ahead of migration. What if one
uses migration really just for emergencies? Why would they
run their guests in always-emulate mode?

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

But quite possibly by far less than after a migration to a system
with a slightly different base frequency. The more that you didn't
even quantify how much drift there may be vs how much of the
inaccuracy is merely because of how we measure.

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

Indeed, others participating would be much appreciated.

Jan



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