WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>, <dan.magenheimer@xxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH 0/2] Improve hpet accuracy
From: "Dave Winchell" <dwinchell@xxxxxxxxxxxxxxx>
Date: Tue, 10 Jun 2008 07:49:09 -0400
Cc: Dave Winchell <dwinchell@xxxxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ben Guthro <bguthro@xxxxxxxxxxxxxxx>
Delivery-date: Tue, 10 Jun 2008 04:47:14 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C473F147.19A3D%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcjIFBNOSTfhtJHySxCkafUaaZcKSgBjZoBVADT1QZAAAzlsiQATIK1ZAAaA51k=
Thread-topic: [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