[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v12] tolerate jitter in cpu_khz calculation to avoid TSC emulation
Am Mon, 11 Mar 2019 05:19:34 -0600 schrieb "Jan Beulich" <JBeulich@xxxxxxxx>: > >>> On 11.03.19 at 11:49, <olaf@xxxxxxxxx> 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:
pgpZaD9AcehPm.pgp _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |