From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: pv_ops dom0 clock only runs under load Date: Fri, 06 Mar 2009 13:56:42 -0800 Message-ID: <49B19C1A.6030309@goop.org> References: <20090306013451.9c7e1f98.listen@mjh.name> <49B0B798.6090304@goop.org> <20090306214649.6e148f55.listen@mjh.name> <20090306222752.d6abc82f.listen@mjh.name> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20090306222752.d6abc82f.listen@mjh.name> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: =?ISO-8859-1?Q?Milan_Holz=E4pfel?= Cc: =?ISO-8859-1?Q?Milan_Holz=E4pfel?= , xen-devel@lists.xensource.com, Keir Fraser List-Id: xen-devel@lists.xenproject.org Milan Holz=E4pfel wrote: > On Fri, 6 Mar 2009 21:46:49 +0100 > Milan Holz=E4pfel wrote: > > =20 >> On Thu, 05 Mar 2009 21:41:44 -0800 >> Jeremy Fitzhardinge wrote: >> >> =20 >>> Milan Holz=E4pfel wrote: >>> >>> =20 >>>> The clock only seems to run if the system is under load (e.g. run >>>> "while true; do echo -n; done" in a shell). =20 >>>> With the CPU loaded and the clock running everything seems to work >>>> quite well (hard disk and network access, that is.) >>>> >>>> Changing the "xen" clocksource to "tsc" via sysfs didn't make a >>>> difference. Enabling or disabling the "tickless" option doesn't mak= e a >>>> difference either.=20 >>>> =20 >>>> =20 >>> That's pretty mysterious; it does suggest your cpu's tsc is not ticki= ng. >>> =20 >> Excerpt from the dmesg (2.6.29 pvops with / without Xen) >> >> [ 4.870697] Marking TSC unstable due to TSC halts in idle >> >> Saw it scrolling by. >> >> [...] >> >> By the way, I booted the 2.6.29 pvops enabled kernel without Xen and >> the tsc timesource only increments when the CPU was loaded, too. On >> 2.6.18 (without Xen) it worked normally (also with the BIOS options >> enabled). >> >> [...] >> >> I will try whether disabling kernel stuff (there is something called >> "cpuidle" compiled in) makes the tsc clocksource work again.=20 >> =20 > > Booting with idle=3Dpoll appended to the kernel command line makes the > TSC work again.=20 > > The "xen" clocksource of the 2.6.29 pvops kernel (under Xen 3.3.1) > works again. 2.6.29 pvops on "bare metal" chooses TSC as default time > source, which works too.=20 > > Doesn't seem like a real solution, does it? The CPU doesn't seem to run > at full load all the time though (temperature stays quite low). > =20 No, its not a great solution. But a tsc which only runs while the cpu=20 is non-idle isn't a huge problem; it just needs Xen to update the timing=20 parameters each time it idles the CPU. But its a bit of a mystery that=20 2.6.18.8 works OK... > Another question: The xm dmesg I posted reports "(XEN) Platform timer > is 14.318MHz HPET". Why is the TSC used for time keeping then? The > HPET works perfectly on every kernel not running under Xen.=20 > =20 Xen uses the hpet to maintain a notion of system-wide time. However its=20 fairly expensive to read the hpet, so each CPU uses its own local time=20 which is tracked using the tsc and synchronized with the hpet. J