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

["Yu Ke" <mr.yuke@xxxxxxxxx>]

2008/10/28 Keir Fraser <keir.fraser@xxxxxxxxxxxxx>:
> On 28/10/08 06:57, "Yu, Ke" <ke.yu@xxxxxxxxx> wrote:
>
>> - Per Keir's comment, more usage is found: use the range timer in HVM virtual
>> periodic timer (xen/arch/x86/hvm/vpt.c). Since vpt has the logic to handle
>> missing ticks, it is an ideal place to use range timer.
>
> The fact is that just about any timer in Xen could be much sloppier than it
> is. What about if we just make slop configurable and change the default up
> to say 1ms? Then for lower power you could bump it some more at the cost of
> things like scheduling getting a bit less accurate (and frankly does that
> matter? :-).

That is doable. my only concern is that the slop configuration is
global and will affect all the timer, it may be hard to choose an
acceptable and reasonable value. current 50ns TIMER_SLOP may be the up
limit. I am not sure if it is appropriate to set the TIME_SLOP to as
large as 1ms.

> My fear with range timers is that it'll actually creep out to
> nearly all current users of the timer interface, and they'll all need to
> express some slightly suspect policy about how much inaccuracy they can cope
> with. Fact is, in just about all cases, that's not an obvious thing to be
> able to specify. In fact it's a tradeoff -- e.g., between power consumption
> and 'accuracy' -- which is perhaps better centrally managed and why I think
> some centrally tweakable knob like the existing SLOP macro may actually be a
> better thing to work with.
>
>  -- Keir
>

the range timer implementation still keep the original set_timer API,
which is a special type of range timer whose expire range is [a,a], so
the semantic of the set_timer is exactly the same as before. For those
user  who did not want to tolorate the inaccuracy, they can still use
the set_timer as before.

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.

Best Regards
Ke

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