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

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

2008/10/30 Keir Fraser <keir.fraser@xxxxxxxxxxxxx>:
> On 30/10/08 08:08, "Yu, Ke" <ke.yu@xxxxxxxxx> wrote:
>
>>> Increasing SLOP to 1ms should have the the similar 5% gain, as your
>>> analysis, it is the worst case of range timer application in vpt. I
>>> can redo the measurement to double confirm.
>>
>> I have finished the measurement, when TIME_SLOP increase to 1ms, there is
>> similar power consumption gain, this time it is 4% (14.0W vs 14.6W) . By
>> theory 1ms TIMER_SLOP should have more gain than the range timer. The
>> diferrence may be due to the test environment noise.
>
> It may also be because your patch tends to delay the timer deadline
> somewhat, and so by the time it goes off you actually sometimes have one or
> two more timers you can deliver in the batch? OTOH it could be experimental
> noise as you suggest, and certainly this change gets us pretty close to your
> win. We'd have to do further experiments to see if increasing TIMER_SLOP
> noticeably degrades system performance, but we'd need to do that with the
> range-timer approach too.

oh yes, you remind me that the range timer also has 50ns TIMER_SLOP,
this may also help. and yes, I am doing the range timer performance
test, to make sure it does not hurt performance. I can also test the
performance of 1ms TIMER_SLOP.

>
> One thing: as Dan pointed out, some things don't want to get their timeout
> early, but generally callers are much more tolerant of getting timeouts a
> bit late. Possibly we should set the timer_deadline to nearest timeout +
> TIMER_SLOP, and then when executing timers be strict about not executing
> timers early (or at least no more than the existing 50us 'mini' slop)?

yes, this way can avoid the issue Dan pointed out.

>
> 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] :)

Best Regards
Ke

>
> I'm thinking out loud. :-)
>
>  -- Keir
>

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