On Wed, Jun 27, 2018 at 11:05 AM, Jung-uk Kim <jkim_at_freebsd.org> wrote: > On 06/27/2018 12:47, Alan Somers wrote: > > On Wed, Jun 27, 2018 at 10:36 AM, Jung-uk Kim <jkim_at_freebsd.org > > <mailto:jkim_at_freebsd.org>> wrote: > > > > On 06/27/2018 03:14, Andriy Gapon wrote: > > > > > > It seems that TSC calibration in virtual machines sometimes can do > more harm > > > than good. Should we default to trusting the information provided > by a hypervisor? > > > > > > Specifically, I am observing a problem on GCE instances where > calibrated TSC > > > frequency is about 10% lower than advertised frequency. And > apparently the > > > advertised frequency is the right one. > > > > > > I found this thread with similar reports and a variety of > workarounds from > > > administratively disabling the calibration to switching to a > different timecounter: > > > https://lists.freebsd.org/pipermail/freebsd-cloud/2017- > January/000080.html > > <https://lists.freebsd.org/pipermail/freebsd-cloud/2017- > January/000080.html> > > > > We already do that for VMware hosts since r221214. > > > > https://svnweb.freebsd.org/changeset/base/221214 > > <https://svnweb.freebsd.org/changeset/base/221214> > > > > We should do the same for each hypervisor. > > > > We probably should. But why does calibration fail in the first place? > Because multiple guests are sharing same physical CPUs and guest OS has > no control, timing cannot be 100% accurate. > > > If it can fail in a VM, then it can probably fail on bare metal too. It > > would be worth investigating. > It does not "fail" in bare metal because we have almost complete control. > > Jung-uk Kim > > Makes sense. I didn't realize that it ran before the scheduler or interrupts were started.Received on Wed Jun 27 2018 - 15:06:21 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:16 UTC