From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: time does not move forward in HVM guests Date: Tue, 4 Jul 2017 18:34:09 +0200 Message-ID: <20170704163326.GA22633@aepfle.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5281486337183233174==" Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org --===============5281486337183233174== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GID0FwUMdk1T2AWN" Content-Disposition: inline --GID0FwUMdk1T2AWN Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In my testing with sysbench in a HVM domU running a linux-4.4 based pvops kernel on a xen-4.7 based dom0 the time does not move forward properly: There (URL below) is basically code like this: clock_gettime(CLOCK_MONOTONIC, a) do_work clock_gettime(CLOCK_MONOTONIC, b) diff_time(a,b) All 'do_work' does is writing zeros to a block of memory. clock_getres(CLOCK_MONOTONIC) indicates a resolution of 1ns. If 'do_work' takes like 100ns or less: a==b. I think this is something that should not happen. In case of vcpu overcommit this happens also when 'do_work' takes around 800ns. At some point I have also seen cases of time going backward. I can not reproduce this anymore, might have been bugs in my code or the domU.cfg changed. A workaround is booting the domU kernel with 'clocksource=tsc nohz=off highres=off'. Why does this happen? Are the expectations too high? Olaf https://github.com/olafhering/sysbench/compare/master...pv bash autogen.sh make -j bash mem.1K.on.sh --GID0FwUMdk1T2AWN Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSkRyP6Rn//f03pRUBdQqD6ppg2fgUCWVvDbgAKCRBdQqD6ppg2 fgOMAKDjRgy8z6yStK/HUlCqjO9q5mtAxwCdF7MI00tGQdPUE07UOICZ8Fq8BJ0= =5Azs -----END PGP SIGNATURE----- --GID0FwUMdk1T2AWN-- --===============5281486337183233174== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============5281486337183233174==--