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: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0/2] range timer support
From: "Yu Ke" <mr.yuke@xxxxxxxxx>
Date: Tue, 28 Oct 2008 23:15:24 +0800
Cc: "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>, "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Wei, Gang" <gang.wei@xxxxxxxxx>, "Yu, Ke" <ke.yu@xxxxxxxxx>
Delivery-date: Tue, 28 Oct 2008 08:15:45 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=RLIFyaNAzYnHAKoFEi50WX8aNgGSirs16OlakjWTBlU=; b=SAlrOLno/gg1oy8y4F27DROylWOqXEfVcNSFK+E70hoG7UjRGQ6m7qzgTusS9sDs1i nAWkbvLueZPpT6W+dTdyrrD6ocoDcYe+t3G/D+fW3iKy+ra+wC1cwpTXDZcviqxVKjYo VJGEMXyJE7g9sjfocXjscQNURtJzLEJwYJjJU=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=oKR2DG3JUshBbLfDigFMr4IV3S8aBu8dBQjNZanHoXawko+TPxNpl94C1vXYnzVnIs 3myESelQBwj/LN/RnNk79wGxCHEkKYvOT58wvEj89n55RFVC8NU8T84+Mxz18D2mLXCJ o1od/E+CbBWTA0ISF6XxDJQMKQGK4Pc9823Nk=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C52CAA3C.28764%keir.fraser@xxxxxxxxxxxxx>
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>
References: <49582C73AC36CC4C8C6C42390304E81C092F97F902@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C52CAA3C.28764%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
2008/10/28 Keir Fraser <keir.fraser@xxxxxxxxxxxxx>:
> On 28/10/08 06:57, "Yu, Ke" <ke.yu@xxxxxxxxx> wrote:
>
>> - Per Keir's comment, more usage is found: use the range timer in HVM virtual
>> periodic timer (xen/arch/x86/hvm/vpt.c). Since vpt has the logic to handle
>> missing ticks, it is an ideal place to use range timer.
>
> The fact is that just about any timer in Xen could be much sloppier than it
> is. What about if we just make slop configurable and change the default up
> to say 1ms? Then for lower power you could bump it some more at the cost of
> things like scheduling getting a bit less accurate (and frankly does that
> matter? :-).

That is doable. my only concern is that the slop configuration is
global and will affect all the timer, it may be hard to choose an
acceptable and reasonable value. current 50ns TIMER_SLOP may be the up
limit. I am not sure if it is appropriate to set the TIME_SLOP to as
large as 1ms.

> My fear with range timers is that it'll actually creep out to
> nearly all current users of the timer interface, and they'll all need to
> express some slightly suspect policy about how much inaccuracy they can cope
> with. Fact is, in just about all cases, that's not an obvious thing to be
> able to specify. In fact it's a tradeoff -- e.g., between power consumption
> and 'accuracy' -- which is perhaps better centrally managed and why I think
> some centrally tweakable knob like the existing SLOP macro may actually be a
> better thing to work with.
>
>  -- Keir
>

the range timer implementation still keep the original set_timer API,
which is a special type of range timer whose expire range is [a,a], so
the semantic of the set_timer is exactly the same as before. For those
user  who did not want to tolorate the inaccuracy, they can still use
the set_timer as before.

and IMHO, the power consumption and inaccuracy trade-off is not a
central policy, each user know better about its tolerance, so it may
be better to let user to decide.

Best Regards
Ke

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