Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 22 Feb 2019 15:28:36 +0100
From:   Olaf Hering <olaf@aepfle.de>
To:     Paolo Bonzini <pbonzini@redhat.com>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        John Stultz <john.stultz@linaro.org>,
        Stephen Boyd <sboyd@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>, x86@kernel.org
Subject: Re: recalibrating x86 TSC during suspend/resume
Message-ID: <20190222142836.GA14744@aepfle.de>
References: <20190222105302.GA26398@aepfle.de>
 <alpine.DEB.2.21.1902221212190.1777@nanos.tec.linutronix.de>
 <036fab04-0c1b-134d-a170-399b2dc6ab5f@redhat.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
        protocol="application/pgp-signature"; boundary="SLDf9lqlvOQaIe6s"
Content-Disposition: inline
In-Reply-To: <036fab04-0c1b-134d-a170-399b2dc6ab5f@redhat.com>
User-Agent: Mutt/1.11.3 (20190207T234809.c483d3c3)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


--SLDf9lqlvOQaIe6s
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 22, Paolo Bonzini wrote:

> On 22/02/19 12:44, Thomas Gleixner wrote:
> >> The specific usecase I have is a workload within VMs that makes heavy
> >> use of TSC. The kernel is booted with 'clocksource=3Dtsc highres=3Doff=
 nohz=3Doff'
> >> because only this clocksource gives enough granularity. The default
> >> paravirtualized clock will return the same values via
> >> clock_gettime(CLOCK_MONOTONIC) if the timespan between two calls is too
> >> short. This does not happen with 'clocksource=3Dtsc'.
>=20
> This shouldn't happen.  clock_gettime(CLOCK_MONOTONIC) should be
> monotonic increasing.  Do you have a testcase?

Two years ago I tweaked sysbench to track the execution time of the
'memory' test:

https://github.com/olafhering/sysbench
https://github.com/olafhering/sysbench/blame/pv/src/tests/memory/sb_memory.c

The checks in diff_timespec() triggered with clocksource=3Dxen, but I can
not reproduce it right now with 5.0 and 4.4 based kernels. I have no
data how KVM behaves. In the end the hypervisor was tweaked to tolerate
a certain jitter in expected TSC speed before emulation kicks in. Up to
~1MHz would be ok to stay within the 500PPM limit that ntpd can handle.

But now there is that "island" issue that needs to be resolved in one
way or another.

Olaf

--SLDf9lqlvOQaIe6s
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQSkRyP6Rn//f03pRUBdQqD6ppg2fgUCXHAHEAAKCRBdQqD6ppg2
fnzCAKCxHIeYXFSa14XpUTZpfglkb21WywCg7EFBbRgWebESoVVMPmQkLBshGRQ=
=JtGU
-----END PGP SIGNATURE-----

--SLDf9lqlvOQaIe6s--