|
xen-devel
Re: [Xen-devel] [PATCH 0/2] range timer support
|
To: |
Yu Ke <mr.yuke@xxxxxxxxx> |
|
Subject: |
Re: [Xen-devel] [PATCH 0/2] range timer support |
|
From: |
Keir Fraser <keir.fraser@xxxxxxxxxxxxx> |
|
Date: |
Tue, 28 Oct 2008 15:37:09 +0000 |
|
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:37:32 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<631d03500810280815y3a415fb2n358f1ebd74111571@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> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
Thread-index: |
Ack5EwnmSI0IOKUGEd2ghgAX8io7RQ== |
|
Thread-topic: |
[Xen-devel] [PATCH 0/2] range timer support |
|
User-agent: |
Microsoft-Entourage/11.4.0.080122 |
On 28/10/08 15:15, "Yu Ke" <mr.yuke@xxxxxxxxx> wrote:
> 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.
Yes, I can see there is a fundamental difference in points of view here. I
would point out that, in your second patch, it's not clear there's any
particular reason for the constants chosen in:
MIN(pt->period/8, MILLISECS(1))
How did you arrive at this formula? Why 1ms rather than 2ms, 10ms, or 500us?
Why 8 rather than 16 or 4? Ultimately the entity that really knows what
bounds are reasonable on sloppiness of a guest timer device would be the
guest itself: the kernel, or applications running on it, or users
interacting with that guest software. Otherwise I think you're making a
somewhat uninformed tradeoff between performance and power. And in that
case, if the balance point doesn't need to be chosen all that accurately,
then centralising and hiding the sloppiness seems a good idea to me. Also
that allows the potential for easier central tunability: do you want
performance more than power, or vice versa?
-- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home