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" <ke.yu@xxxxxxxxx>
Date: Thu, 30 Oct 2008 16:08:40 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>, "Tian, Kevin" <kevin.tian@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Wei, Gang" <gang.wei@xxxxxxxxx>
Delivery-date: Thu, 30 Oct 2008 01:09:12 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <631d03500810290345v68a1bbf0t1ba236cace1a0334@xxxxxxxxxxxxxx>
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: <D8078B8B3B09934AA9F8F2D5FB3F28CE09395A5FA0@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C52DCF34.1EA2E%keir.fraser@xxxxxxxxxxxxx> <631d03500810290345v68a1bbf0t1ba236cace1a0334@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Ack5s4BF0I0qvHXHTcCbN8k2fsl5+wAsigPQ
Thread-topic: [Xen-devel] [PATCH 0/2] range timer support
Yu Ke wrote:
> 2008/10/29 Keir Fraser <keir.fraser@xxxxxxxxxxxxx>:
>> 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. 
> 
> Increasing SLOP to 1ms should have the the similar 5% gain, as your
> analysis, it is the worst case of range timer application in vpt. I
> can redo the measurement to double confirm.

I have finished the measurement, when TIME_SLOP increase to 1ms, there is 
similar power consumption gain, this time it is 4% (14.0W vs 14.6W) . By theory 
1ms TIMER_SLOP should have more gain than the range timer. The diferrence may 
be due to the test environment noise.

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