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

From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH v12] tolerate jitter in cpu_khz calculation to avoid TSC emulation
Date: Mon, 11 Mar 2019 12:57:43 +0100	[thread overview]
Message-ID: <20190311125743.0f9493c1.olaf@aepfle.de> (raw)
In-Reply-To: <5C864446020000780021D29A@prv1-mh.provo.novell.com>

[-- Attachment #1.1: Type: text/plain, Size: 2431 bytes --]

Am Mon, 11 Mar 2019 05:19:34 -0600
schrieb "Jan Beulich" <JBeulich@suse.com>:

> >>> On 11.03.19 at 11:49, <olaf@aepfle.de> wrote:  
> > I do not see how the HVM domU clock can be without drift if it does not
> > sync with an external source. It seems xenlinux based PV drivers lack
> > a clocksource, so they would better run ntp.  
> Yes indeed. But it still cannot be a requirement. There may be people
> wanting to fully isolate their systems.

They are free to isolate them. Still, there has to be a source to keep
time in sync. One of the involved dom0s can be declared as reference.
I'm not seeing how this change does affect the time within such domUs
in a significant way. Time will move forward at slightly different speed
when running on both hosts.

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

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

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

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

Olaf

[-- Attachment #1.2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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