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