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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] 
>Sent: Tuesday, October 28, 2008 11:37 PM
>
>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?
>

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.

Actually range timer doesn't hurt performance much as immediately
imagined, especially for periodical timers. Normally just 1st 
alignment may not follow assigned interval, and once they're aligned,
later behavior should be similar as before.

Thanks,
Kevin

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