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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 11.03.19 at 12:57, <olaf@xxxxxxxxx> wrote:
> Am Mon, 11 Mar 2019 05:19:34 -0600
> schrieb "Jan Beulich" <JBeulich@xxxxxxxx>:
> 
>> Plus - is your change somehow limited to HVM guests? I can't seem to
>> spot why that would be. And if it isn't, then leaving PV guests out of
>> the discussion is simply wrong.
> 
> tsc_set_info exits early for non-HVM, so I think PV just does not have vtsc?

It does exit early, but only for PV hwdom afaics.

>> Also I'm having trouble seeing how the connection to "drift" has come
>> up all of the sudden. Your change is to deal with singular events
>> (migration) aiui.
> 
> "drift" as in "TSC runs at different speed than reference clock"?
> It is the migration/restore that enables emulation of TSC access.

Well, "drift" to me means something that changes slowly. The
change during migration is a single discontinuity though, even when
capped at 200MHz.

>> > Then the inaccuracy has to be handled, Xen can not know if cpu_khz is 
>> > correct.
>> > As said above, the observed range was 200, so this will be subtracted.  
>> 
>> This is what I consider wrong, because it results in
>> 
>>    tmp (initial)     |   tmp (result)
>>    198               |   198
>>    199               |   199
>>    200               |   0
>>    201               |   1
>>    ...
>>    398               |   198
>>    399               |   199
>>    400               |   0
>>    401               |   1
> 
> Why does it become 0 here?

Oops, this second instance should have had 200 and 201 respectively.

>> I'd expect you to _cap_ at 200 instead. But of course the seemingly
>> random 200 will itself need a much better reasoning, or at least a
>> clear indication of the data base (number of different systems) that
>> it was derived from. "Large number of hosts", after all, may mean 12
>> to you and tens of thousands to me.
> 
> The formula reduces the calculated number by a constant. tmp would reach
> zero on a 400MHz host. Assuming that still exists, the worst case is emulation
> of TSC access. If the check would be (tmp > 200), tmp would become 1 khz
> of difference. I think either '>' or '>=' would be fine on such system.

The question is not whether to use > or >= ; the question is how
the step from 199 to 200 (or from 200 to 201) can sensibly be the
way you've coded it. But perhaps I'm simply missing something here.

Jan



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