Yu Ke wrote:
> 2008/10/30 Keir Fraser <keir.fraser@xxxxxxxxxxxxx>:
>> On 30/10/08 08:08, "Yu, Ke" <ke.yu@xxxxxxxxx> wrote:
>>
>>
>> Or perhaps actually having range timers in timer.c is worthwhile for
>> future extensions and for now we can just set every timer to
>> [deadline, deadline+configurable_global_slop]. Then the existing
>> range-timer mechanism ought to find a sensible deadline to aim for,
>> only delaying timer events when there is a benefit to doing so.
>
> I am fine with configurable global slop, although some timer may not
> benefit much from this. e.g. the 50HZ (20ms) cpufreq DBS timer, whose
> timer range can be at least [deadline, deadline+5ms] :)
>
Looks I misunderstand your points. Do you mean using the range timer
implementation to implement the interface of [deadline,
deadline+configurable_global_slop]? If so, I would more prefer this approach
and would be happy to revise the patch:) Compared to the first approach, i.e.
setting the timer_deadline to nearest timeout +TIMER_SLOP TIME_SLOP , range
timer implementation does have advantage. In the first approach, the timer
would be always delayed, even when those timers are aligned. While range timer
would only delay those timer at the first time, and then would expires without
delay.
For example, think about two 250HZ timers t1, t2, which will expire at T and
T+1ms. Suppose TIMER_SLOP is 1ms, and suppose apic timer deadline is set to
T+1ms.
In the first apporach, the apic timer will expire at:
T+1ms: t1 and t2 is executed, and deadline become T+1ms+4ms, and apic timer
deadline is set to T+1ms+4ms+TIMER_SLOP (T+6ms)
T+6ms: t1 and t2 is executed, and dealine become T+6ms+4ms, and apic timder
deadline is set to T+6ms+4ms+TIMER_SLOP (T+11ms)
T+11ms:......
In the range timer appraoch, the apic timer will expire at:
T+1ms: t1 and t2 is executed, and deadline range become [T+5ms, T+6ms], and
apic timder deadline is set to T+5ms
T+5ms: t1 and t2 is executed, and deadline range become [T+9ms, T+10ms], and
apic timder deadline is set to T+9ms
T+9ms: ......
>From the above scenario, we can see t1 and t2 is always delayed for 1ms in the
>first approach, while not in range timer approach. so range timer is more
>close to the semantic of original timer.
Best Regards
Ke
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home