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

2018-12-14 Thread Olaf Hering
Am Thu, 13 Dec 2018 07:46:36 -0700 schrieb "Jan Beulich" : > >>> On 13.12.18 at 14:25, wrote: > > The question is, how much drift can be tolerated even without my patch. > This depends on what a system is used for. A few seconds off may > be fine for one purpose, but a significant problem for

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

2018-12-13 Thread Jan Beulich
>>> On 13.12.18 at 14:25, wrote: > The question is, how much drift can be tolerated even without my patch. This depends on what a system is used for. A few seconds off may be fine for one purpose, but a significant problem for another. Similarly a sudden (however small) change to the TSC tick rat

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

2018-12-13 Thread Olaf Hering
Am Thu, 13 Dec 2018 03:41:44 -0700 schrieb "Jan Beulich" : > And further argumentation that everyone is using NTP anyway > doesn't make it any better, when it's no-where written down that > Xen is unusable with NTP running in all guests (I'm exaggerating > here just to get the point over). Don't f

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

2018-12-13 Thread Olaf Hering
Am Thu, 13 Dec 2018 03:41:44 -0700 schrieb "Jan Beulich" : > In a second step, let's consider what impact errors in calibration have. > Between two systems with exactly the same hardware crystal > frequency there of course is going to be some drift. The problem > though is - between the two calibr

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

2018-12-13 Thread Jan Beulich
>>> On 13.12.18 at 10:04, wrote: > Am Thu, 13 Dec 2018 01:45:39 -0700 > schrieb "Jan Beulich" : > >> >>> On 13.12.18 at 09:18, wrote: >> > Am Wed, 12 Dec 2018 09:39:25 -0700 >> > schrieb "Jan Beulich" : >> > >> >> >>> On 12.12.18 at 16:20, wrote: >> >> > If a domU uses TSC as clocksour

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

2018-12-13 Thread Olaf Hering
Am Thu, 13 Dec 2018 01:45:39 -0700 schrieb "Jan Beulich" : > >>> On 13.12.18 at 09:18, wrote: > > Am Wed, 12 Dec 2018 09:39:25 -0700 > > schrieb "Jan Beulich" : > > > >> >>> On 12.12.18 at 16:20, wrote: > >> > If a domU uses TSC as clocksoure it also must run NTP in some way to > >> > a

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

2018-12-13 Thread Jan Beulich
>>> On 13.12.18 at 09:18, wrote: > Am Wed, 12 Dec 2018 09:39:25 -0700 > schrieb "Jan Beulich" : > >> >>> On 12.12.18 at 16:20, wrote: >> > If a domU uses TSC as clocksoure it also must run NTP in some way to >> > avoid the potential drift what will most likely happen, independent of >> > any m

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

2018-12-13 Thread Olaf Hering
Am Wed, 12 Dec 2018 09:39:25 -0700 schrieb "Jan Beulich" : > >>> On 12.12.18 at 16:20, wrote: > > If a domU uses TSC as clocksoure it also must run NTP in some way to > > avoid the potential drift what will most likely happen, independent of > > any migration. > Which drift? While anyone's we

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

2018-12-12 Thread Jan Beulich
>>> On 12.12.18 at 16:20, wrote: > Improve decision when vTSC emulation will be activated for a domU with > tsc_mode=default. The current approach is to compare the cpu_khz value > from two physical hosts. Since this value is not accurate, it can not be > used verbatim to decide if vTSC emulation

[Xen-devel] [PATCH v11] tolerate jitter in cpu_khz calculation to avoid TSC emulation

2018-12-12 Thread Olaf Hering
Improve decision when vTSC emulation will be activated for a domU with tsc_mode=default. The current approach is to compare the cpu_khz value from two physical hosts. Since this value is not accurate, it can not be used verbatim to decide if vTSC emulation needs to be enabled. Without this change e