RE: [Xen-devel] [PATCH 0/2] Improve hpet accuracy

["Dave Winchell" <dwinchell@xxxxxxxxxxxxxxx>]

> > I don't recall what prompted me to try end-of-interrupt,
> > but I saw a significant improvement. I may have been running
> > a monotonicity test at the same time to explain the lock
> > contention mentioned in the write-up.

> Doesn¹t this policy guarantee that you actually deliver interrupts at
> consistently too low a rate? Since the delivery period is now timer period +
> latency of interrupt handling?

Yes, the rate ends up being about half the normal rate because
I toss the interrupt if it doesn't meet the requirement. If, in testing, we find
a guest that has a problem with half the normal rate, we can fine tune
the policy. For example, instead of discarding set a small timer.

> I suppose it works for this guest type
> because it doesn¹t actually care about getting interrupts at the correct
> rate, so long as the ticks are always a bit late?

True.

> For those that do need missed ticks to be delivered, do you track missed
> ticks at the absolute correct rate?

Yes.

>
> This is perhaps a fine tradeoff for all platform timers < those guests that
> can handle missed ticks obviously do not care about getting their timer
> interrupts  at absolutely the correct rate, and delivering a little late is
> what they are geared to handle (getting delivered consistently early is just
> weird!). Whereas guests that need all ticks also want them (at least over
> the long run) at exactly the correct rate.

> I think there¹s good empirical analysis in the work you¹ve done. We just
> need the patches cleaned up and generalised for vpt.c now.

Thanks. I'll get to work on the generalization, etc.

-Dave


-----Original Message-----
From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
Sent: Tue 6/10/2008 3:52 AM
To: Dave Winchell; dan.magenheimer@xxxxxxxxxx
Cc: Ben Guthro; xen-devel
Subject: Re: [Xen-devel] [PATCH 0/2] Improve hpet accuracy

On 10/6/08 00:34, "Dave Winchell" <dwinchell@xxxxxxxxxxxxxxx> wrote:

> I don't recall what prompted me to try end-of-interrupt,
> but I saw a significant improvement. I may have been running
> a monotonicity test at the same time to explain the lock
> contention mentioned in the write-up.

Doesn¹t this policy guarantee that you actually deliver interrupts at
consistently too low a rate? Since the delivery period is now timer period +
latency of interrupt handling? I suppose it works for this guest type
because it doesn¹t actually care about getting interrupts at the correct
rate, so long as the ticks are always a bit late?

For those that do need missed ticks to be delivered, do you track missed
ticks at the absolute correct rate?

This is perhaps a fine tradeoff for all platform timers < those guests that
can handle missed ticks obviously do not care about getting their timer
interrupts  at absolutely the correct rate, and delivering a little late is
what they are geared to handle (getting delivered consistently early is just
weird!). Whereas guests that need all ticks also want them (at least over
the long run) at exactly the correct rate.

I think there¹s good empirical analysis in the work you¹ve done. We just
need the patches cleaned up and generalised for vpt.c now.

 -- Keir

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