[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH] Add a timer mode that disables pending missed ticks
I ran a 24 hour (23hr:40min) test. The usual setup. Protocol was ASYNC.
sles9sp3-64: -4.96 sec -.0058%
rh4u4-64: +4.42 sec +.0052%
So, lets leave it ASYNC unless someone produces some test cases
where the error gets up to close to .05%.
I'll do some testing here with overnight runs or, perhaps,
Dave Winchell wrote:
I've added comments below.
See my next mail on some interesting performance numbers.
Keir Fraser wrote:
I agree that this could be a problem. I have an idea that could give
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
ticks at all for a long time, if the guest only runs in short bursts
I/O bound) and happens not to be running on any tick boundary. I'm
how much that matters. It could cause time goes backwards if the time
extrapolation via the TSC is not perfectly accurate, or cause
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
VCPUs under full load may cause us to optimise in ways that have nasty
unexpected effects for other workloads.
SYNC and eliminate the long periods without clock interrupts.
In pt_process_missed_ticks() when missed_ticks > 0 set pt->run_timer = 1.
list_for_each_entry ( pt, head, list )
And in pt_timer_fn():
pt->run_timer = 0;
So, for a guest that misses a tick, we will interrupt him once from the
descheduled state and then leave him alone in the descheduled state.
For default mode as checked into unstable is now,
64 bit guests should run quite fast as missed is calculated and then
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
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
run badly with that because they treat every one of the missed ticks
receive as a full tick.
Sorry, I was confused.
However, the default mode will still run poorly for 64 bit guests because
of the pending_nr's accumulated while the guest has interrupts disabled.
As I recall, the effect is quite large, on the order of 10% error.
I'll get you a number later today.
Or is the lack of
synchronization of TSCs across VCPUs causing issues that you're
This does cause issues, but its not the only contributor to poor
Having TSCs synchronized across vcpus will help some of the time going
backwards problems we have seen, I think.
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
have been missed, but then successive ticks are delivered 'on the
possible middleground? Or perhaps we should just go with SYNC
How do these Linux x64 guests fare with the original and default
by the way? I would expect that time should be accounted pretty
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
Xen-devel mailing list