[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 0/2] range timer support



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.