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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 7/11/07 19:38, "Dave Winchell" <dwinchell@xxxxxxxxxxxxxxx> 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
> 
> 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