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] range timer support

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, Yu Ke <mr.yuke@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0/2] range timer support
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Wed, 29 Oct 2008 08:28:36 +0000
Cc: "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Wei, Gang" <gang.wei@xxxxxxxxx>, "Yu, Ke" <ke.yu@xxxxxxxxx>
Delivery-date: Wed, 29 Oct 2008 01:28:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <D8078B8B3B09934AA9F8F2D5FB3F28CE09395A5FA0@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Ack5EwnmSI0IOKUGEd2ghgAX8io7RQAWJThwAA0t2cQ=
Thread-topic: [Xen-devel] [PATCH 0/2] range timer support
User-agent: Microsoft-Entourage/11.4.0.080122
On 29/10/08 02:29, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:

> Yes, this is a valid concern. Simplicity is better if we're not sure
> the gain by making things complex. I agree that a central slop
> control is cleaner here. In the meantime how about also adding a flag
> to disable slop per-timer base? Then timers with stricter delivery
> requirement can add this flag even when global slop is enabled.
> Or may be this control can be exposed to user by domctl interface,
> as a per-domain configurable option.

I actually wonder whether we would get similar to your 5% win by just
increasing the SLOP parameter to a fixed 1ms. That would equal your
worst-case slop in the second range-timer patch for vpt timers, and I don't
really see why any timer in Xen wouldn't be able to deal with that.

One thing that would be interesting would be some micro-statistics such as
average C3 residency time, to go along with your macro-statistic of total
power consumption. Seeing the relationship between the two would let us see
how much of an effect the residency time has on power consumption and give
us something more precise to aim for in terms of desirable residency time.
We could even hack the C3 code in Xen to deliberately set long timeouts, so
we can measure that relationship more precisely and at extremes. If nothing
else it might tell us what sort of slop is worthwhile and, if that's small
enough, perhaps we can just live with it?

> Actually range timer doesn't hurt performance much as immediately
> imagined, especially for periodical timers. Normally just 1st
> alignment may not follow assigned interval, and once they're aligned,
> later behavior should be similar as before.

I like the range-timer implementation, I'm just not convinced about the
interface. At the moment, I think I'd rather split the interface into usage
types (a bit like you suggest above with your domctl idea) -- e.g., this is
a guest timer, or this is a low-rate periodic timer -- and then hide the
policy about what is good enough from the consumers of those interfaces.
Perhaps the range-timer implementation will still be a useful mechanism
behind such interfaces.

 -- Keir



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