WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] Add a timer mode that disables pending missed ti

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Add a timer mode that disables pending missed ticks
From: Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>
Date: Wed, 07 Nov 2007 14:38:56 -0500
Cc: "Shan, Haitao" <haitao.shan@xxxxxxxxx>, Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Dong, Eddie" <eddie.dong@xxxxxxxxx>, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Delivery-date: Mon, 19 Nov 2007 10:19:54 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C357AAB5.18127%Keir.Fraser@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C357AAB5.18127%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
Hi Keir,

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.

In terms of sending the one ASYNC interrupt, I would say no.
Lets simply give it to him on the next boundary. If we give
it to him ASYNC he will have a big offset to deal with, exactly what
gives him trouble.

> 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.

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.

> 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

Keir Fraser wrote:

On 7/11/07 17:29, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx> 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




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>