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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 7/11/07 17:10, "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx> wrote:

> I don't think this code likes the ASYNC method *at all*. The reason is that
> it estimates how late the tick interrupt is by reading the PIT counter. It
> knows the interrupt should have been triggered when the counter wrapped at
> zero. But of course, if we are delivering ticks in ASYNC mode then quickly
> the time we deliver an interrupt has *nothing* to do with the current PIT
> counter value! Hence the lines that effectively fold max(offset, delay) into
> last_tsc are just not going to work properly, because delay is a uniform
> random variable, and hence we probably lose time.

Actually, no, I don't understand why this code is less accurate with ASYNC
mode. My comments on 'delay' above are not true I think. Both 'delay' and
'offset' are accurate estimates of the time elapsed since the last actual
tick threshold, when the PIT counter rolled over. And hence the logic that
is being applied *should* work...

I wonder if something silly like the following is happening: Because we send
unsynchronised tick interrupts, they can actually be delivered when the PIT
is just about to roll over (but hasn't yet). If that happens we could get a
worst-case disagreement between offset (derived from TSC) and delay (derived
from PIT). Let's say that when we read the TSC it looks like we have just
passed a tick rollover. In that case we will count some whole number of lost
ticks and offset will end up being a very small number (very little 'slop'
after a whole number of ticks is accounted). However, when we read the PIT
it looks like we are just about to roll over (but haven't yet) and so delay
will be a very large number: about as large as it can be. In this case we
will subtract a lot from last_tsc, because it looks like we've had nearly a
full tick of delay. But actually the amount of delay that is getting
subtracted from last_tsc has already been accounted for elsewhere as a full
tick!

If this analysis is the truth of the matter then we would actually expect
the ASYNC mode to cause the guest timeofday to run *fast* rather than slow.

Anyhow, it's bound to be something silly like this. :-)

The SYNC/ASYNC method I was going to propose by the way was going to be, in
pt_process_missed_ticks():
    pt->scheduled += missed_ticks * pt->period;
    if ( mode_is(no_missed_tick_accounting) )
        pt->pending_intr_nr = 1;
    else
        pt->pending_intr_nr += missed_ticks;

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

 -- Keir



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