From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 0/2] Improve hpet accuracy Date: Tue, 10 Jun 2008 08:52:23 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0861170237==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Mime-version: 1.0 Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dave Winchell , dan.magenheimer@oracle.com Cc: xen-devel , Ben Guthro List-Id: xen-devel@lists.xenproject.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0861170237== Content-type: multipart/alternative; boundary="B_3295932747_18492253" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3295932747_18492253 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable On 10/6/08 00:34, "Dave Winchell" 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=B9t 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=B9t 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 =8B 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 jus= t weird!). Whereas guests that need all ticks also want them (at least over the long run) at exactly the correct rate. I think there=B9s good empirical analysis in the work you=B9ve done. We just need the patches cleaned up and generalised for vpt.c now. -- Keir --B_3295932747_18492253 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Xen-devel] [PATCH 0/2] Improve hpet accuracy On 10= /6/08 00:34, "Dave Winchell" <dwinchell@virtualiron.com> wro= te:

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 beca= use it doesn’t actually care about getting interrupts at the correct r= ate, so long as the ticks are always a bit late?

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

This is perhaps a fine tradeoff for all platform timers — those guest= s that can handle missed ticks obviously do not care about getting their tim= er interrupts  at absolutely the correct rate, and delivering a little = late is what they are geared to handle (getting delivered consistently ea= rly 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
 --B_3295932747_18492253-- --===============0861170237== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --===============0861170237==--