78 messages in com.xensource.lists.xen-develRe: [Xen-devel] [PATCH] Add a timer m...
FromSent OnAttachments
Shan, Haitao30 Oct 2007 07:27.patch
Keir Fraser30 Oct 2007 09:12 
Dave Winchell30 Oct 2007 14:15.vpt, .c
Shan, Haitao30 Oct 2007 20:09.patch
Keir Fraser31 Oct 2007 00:09 
Dave Winchell01 Nov 2007 14:14.patch
Dave Winchell01 Nov 2007 14:21 
Keir Fraser02 Nov 2007 02:40 
Dave Winchell02 Nov 2007 08:50 
Keir Fraser02 Nov 2007 09:14 
Keir Fraser02 Nov 2007 09:35 
Dave Winchell02 Nov 2007 11:05 
Dave Winchell03 Nov 2007 14:17.Other
Keir Fraser03 Nov 2007 15:31.patch
Dave Winchell05 Nov 2007 06:36 
Dave Winchell07 Nov 2007 06:38.Other
Keir Fraser07 Nov 2007 06:39 
Dave Winchell07 Nov 2007 08:22 
Keir Fraser07 Nov 2007 09:10 
Keir Fraser07 Nov 2007 09:28 
Keir Fraser07 Nov 2007 09:47 
Dave Winchell07 Nov 2007 11:38 
Keir Fraser08 Nov 2007 00:07 
Dave Winchell08 Nov 2007 06:42 
Keir Fraser08 Nov 2007 06:52 
Dave Winchell08 Nov 2007 06:57 
Dave Winchell08 Nov 2007 07:08 
Dave Winchell09 Nov 2007 11:22.patch
Keir Fraser10 Nov 2007 02:54 
Dave Winchell12 Nov 2007 07:37 
Dave Winchell26 Nov 2007 12:57 
Keir Fraser06 Dec 2007 03:56 
Dan Magenheimer19 Dec 2007 10:56 
Dave Winchell19 Dec 2007 11:32 
Dave Winchell19 Dec 2007 11:39 
Dan Magenheimer03 Jan 2008 14:57 
Dave Winchell03 Jan 2008 15:23 
Dave Winchell04 Jan 2008 15:23.time
Keir Fraser08 Jan 2008 06:32 
Dave Winchell09 Jan 2008 08:52 
Dan Magenheimer09 Jan 2008 09:18 
Keir Fraser09 Jan 2008 11:13 
Dan Magenheimer25 Jan 2008 15:50.png
Dave Winchell27 Jan 2008 13:21 
Dan Magenheimer27 Jan 2008 16:29 
Dave Winchell28 Jan 2008 07:20 
Dan Magenheimer29 Jan 2008 14:34.png
Dave Winchell30 Jan 2008 07:24 
Deepak Patel30 Jan 2008 13:03 
Dave Winchell30 Jan 2008 13:44 
Dan Magenheimer01 Feb 2008 14:30.png
Dave Winchell04 Feb 2008 12:06 
Dave Winchell08 Feb 2008 13:20 
Dave Winchell11 Feb 2008 08:52.png
Dave Winchell14 Feb 2008 07:59 
Dan Magenheimer14 Feb 2008 08:20 
Dave Winchell14 Feb 2008 09:55 
Dan Magenheimer15 Feb 2008 08:46 
Dave Winchell15 Feb 2008 09:27 
Dave Winchell19 Feb 2008 07:26 
Dan Magenheimer19 Feb 2008 09:55 
Keir Fraser19 Feb 2008 11:29 
Dave Winchell19 Feb 2008 12:50 
Dan Magenheimer19 Feb 2008 15:37 
Dan Magenheimer20 Feb 2008 15:40 
Dan Magenheimer25 Feb 2008 08:41 
Dave Winchell25 Feb 2008 12:00 
Keir Fraser26 Feb 2008 00:25 
Dave Winchell26 Feb 2008 06:45 
Keir Fraser26 Feb 2008 06:56 
Dave Winchell26 Feb 2008 07:48 
Dave Winchell05 Mar 2008 07:06 
Keir Fraser05 Mar 2008 07:19 
Keir Fraser05 Mar 2008 09:20 
Dave Winchell05 Mar 2008 09:25 
Dave Winchell05 Mar 2008 09:42 
Dan Magenheimer05 Mar 2008 09:53 
Dan Magenheimer06 Mar 2008 15:35 
Subject:Re: [Xen-devel] [PATCH] Add a timer mode that disables pending missed ticks
From:Keir Fraser (Keir@cl.cam.ac.uk)
Date:11/08/2007 12:07:25 AM
List:com.xensource.lists.xen-devel

On 7/11/07 19:38, "Dave Winchell" <dwin@virtualiron.com> wrote:

My feeling is that we should go full SYNC. Yes, in theory the guests should be able to handle ASYNC, but in reality it appears that some do not. Since it is easy for us to give them SYNC, lets just do it and not stress them out.

One problem with pure SYNC is there's a fair chance you won't deliver any ticks at all for a long time, if the guest only runs in short bursts (e.g., I/O bound) and happens not to be running on any tick boundary. I'm not sure how much that matters. It could cause time goes backwards if the time extrapolation via the TSC is not perfectly accurate, or cause problems if there are any assumptions that TSC delta since last tick fits in 32 bits (less likely in x64 code I suppose). Anyway, my point is that only testing VCPUs under full load may cause us to optimise in ways that have nasty unexpected effects for other workloads.

For default mode as checked into unstable is now, 64 bit guests should run quite fast as missed is calculated and then a bunch of additional interrupts are delivered. On the other hand 32bit guests very well in default mode.

For the original code, before we put in the constant tsc offset business, 64bit guests run poorly and 32bit quests very well time-wise.

The default mode hasn't changed. Are you under the impression that missed-ticks-but-no-delay-of-tsc is the default mode now? I know x64 guests run badly with that because they treat every one of the missed ticks they receive as a full tick.

-- Keir

Or is the lack of synchronization of TSCs across VCPUs causing issues that you're trying to avoid?

This does cause issues, but its not the only contributor to poor timing. Having TSCs synchronized across vcpus will help some of the time going backwards problems we have seen, I think.

Regards, Dave

On 7/11/07 17:29, "Keir Fraser" <Keir@cl.cam.ac.uk> wrote:

So, you can see we send an interrupt immediately (and ASYNC) if any ticks have been missed, but then successive ticks are delivered 'on the beat'. A possible middleground? Or perhaps we should just go with SYNC after all...

How do these Linux x64 guests fare with the original and default timer mode, by the way? I would expect that time should be accounted pretty accurately in that mode, albeit with more interrupts than you'd like. Or is the lack of synchronisation of TSCs across VCPUs causing issues that you're trying to avoid?

-- Keir