|
xen-devel
RE: [Xen-devel] [PATCH 0/2] Improve hpet accuracy
> > 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.
A better solution is to set the new period timer at end-of-interrupt time
(in the callback) instead of delivery time (timer expiration time).
This way the rate will be very close to what the guest expects.
I think I'll make this change.
-Dave
-----Original Message-----
From: Dave Winchell
Sent: Tue 6/10/2008 7:49 AM
To: Keir Fraser; dan.magenheimer@xxxxxxxxxx
Cc: Ben Guthro; xen-devel; Dave Winchell
Subject: RE: [Xen-devel] [PATCH 0/2] Improve hpet accuracy
> > 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
|
|
|
Home