Date: Wed, 27 Jun 2018 13:05:10 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: Alan Somers <asomers@freebsd.org> Cc: Andriy Gapon <avg@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: TSC calibration in virtual machines Message-ID: <0984f859-bce2-3dcb-40ba-58bb61598e1b@FreeBSD.org> In-Reply-To: <CAOtMX2gcUybMhPdEzBWX07-oPdmJdqn%2BvW7KkNZvs2sFmcHFNw@mail.gmail.com> References: <8ac353c5-d188-f432-aab1-86f4ca5fd295@FreeBSD.org> <4d7957f6-9497-19ff-4dbb-436bb6b05a56@FreeBSD.org> <CAOtMX2gcUybMhPdEzBWX07-oPdmJdqn%2BvW7KkNZvs2sFmcHFNw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --I6pGaQ5DvOJY0xQeNb9GGZBU4SvrZ2rst Content-Type: multipart/mixed; boundary="2MGmki2NJfPcbAiF1fTO7BLsifonTMqLQ"; protected-headers="v1" From: Jung-uk Kim <jkim@FreeBSD.org> To: Alan Somers <asomers@freebsd.org> Cc: Andriy Gapon <avg@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Message-ID: <0984f859-bce2-3dcb-40ba-58bb61598e1b@FreeBSD.org> Subject: Re: TSC calibration in virtual machines References: <8ac353c5-d188-f432-aab1-86f4ca5fd295@FreeBSD.org> <4d7957f6-9497-19ff-4dbb-436bb6b05a56@FreeBSD.org> <CAOtMX2gcUybMhPdEzBWX07-oPdmJdqn+vW7KkNZvs2sFmcHFNw@mail.gmail.com> In-Reply-To: <CAOtMX2gcUybMhPdEzBWX07-oPdmJdqn+vW7KkNZvs2sFmcHFNw@mail.gmail.com> --2MGmki2NJfPcbAiF1fTO7BLsifonTMqLQ Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 06/27/2018 12:47, Alan Somers wrote: > On Wed, Jun 27, 2018 at 10:36 AM, Jung-uk Kim <jkim@freebsd.org > <mailto:jkim@freebsd.org>> wrote: >=20 > On 06/27/2018 03:14, Andriy Gapon wrote: > >=20 > > It seems that TSC calibration in virtual machines sometimes can d= o more harm > > than good.=C2=A0 Should we default to trusting the information pr= ovided by a hypervisor? > >=20 > > Specifically, I am observing a problem on GCE instances where cal= ibrated TSC > > frequency is about 10% lower than advertised frequency.=C2=A0 And= apparently the > > advertised frequency is the right one. > >=20 > > I found this thread with similar reports and a variety of workaro= unds from > > administratively disabling the calibration to switching to a diff= erent timecounter: > > https://lists.freebsd.org/pipermail/freebsd-cloud/2017-January/00= 0080.html > <https://lists.freebsd.org/pipermail/freebsd-cloud/2017-January/000= 080.html> >=20 > We already do that for VMware hosts since r221214. >=20 > https://svnweb.freebsd.org/changeset/base/221214 > <https://svnweb.freebsd.org/changeset/base/221214>; >=20 > We should do the same for each hypervisor. >=20 > We probably should.=C2=A0 But why does calibration fail in the first pl= ace? 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.=C2= =A0 It > would be worth investigating. It does not "fail" in bare metal because we have almost complete control.= Jung-uk Kim --2MGmki2NJfPcbAiF1fTO7BLsifonTMqLQ-- --I6pGaQ5DvOJY0xQeNb9GGZBU4SvrZ2rst Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEl1bqgKaRyqfWXu/CfJ+WJvzb8UYFAlszw8YACgkQfJ+WJvzb 8UYVxQf/ThwArM/OpiePmcwU+d5/sVUMRPnYZdRmsaYSkp+rvnBUH1e+fGJpnO+V Tu1TkpcvHNfPYwYOIE+84VP4sAcfI5Ex9wBxhZ8RrrGQ6zJKujK/kd3CALZgHMc6 QUhpHkuMbu+dBTI9uvW8RuEWlRsr4GBmk8XxOPSQlLPTsSTP9wlhWdcRdq76zsm1 jr0dUNYn8ZVeW/pAr4F/h1VF+4HhwOUJXkLQgZWJflFqzNmmaRFakkm4eT6onTBN k9mRxe1DrZ+kDjrhdgv7kjmW9TU9tt56NpC92K9+VY5nJhcuKBt3AZsmgqQ2j5g7 4gSP9ipS+Zbzj9vvwJ3RxsruD6AloQ== =mbHv -----END PGP SIGNATURE----- --I6pGaQ5DvOJY0xQeNb9GGZBU4SvrZ2rst--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0984f859-bce2-3dcb-40ba-58bb61598e1b>