Re: [PATCH 0/2] range timer support

[Keir Fraser <keir.fraser@eu.citrix.com>]

On 30/10/08 08:08, "Yu, Ke" <ke.yu@intel.com> 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.

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)?

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'm thinking out loud. :-)

 -- Keir