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
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [Xen-devel] [PATCH 0/2] range timer support, (continued)
- Re: [Xen-devel] [PATCH 0/2] range timer support, Keir Fraser
- RE: [Xen-devel] [PATCH 0/2] range timer support,
Yu, Ke <=
- Re: [Xen-devel] [PATCH 0/2] range timer support, Keir Fraser
- Re: [Xen-devel] [PATCH 0/2] range timer support, Yu Ke
- RE: [Xen-devel] [PATCH 0/2] range timer support, Yu, Ke
- Re: [Xen-devel] [PATCH 0/2] range timer support, Keir Fraser
- RE: [Xen-devel] [PATCH 0/2] range timer support, Yu, Ke
- Re: [Xen-devel] [PATCH 0/2] range timer support, Keir Fraser
- RE: [Xen-devel] [PATCH 0/2] range timer support, Yu, Ke
- Re: [Xen-devel] [PATCH 0/2] range timer support, Keir Fraser
|
|
|