On Thu, Oct 18, 2007 at 09:44:35PM +0200, Joerg Sonnenberger wrote:
> Hi all,
> attached patch is a first big step to allow operation with dynamic
> timers.

Why do you think this is a good idea?
My 'gut feeling' is that it is a bad one.
I can see reasons for not actually taking an interrupt on every tick,
but if you remove 'ticks' completely then you will have problems
with busy systems taking far too many timer interupts - since you will
rarely do the work for more than one expired callout per interrupt.

> I don't think that the hashed time wheel works very effective
> for the much larger possible range of values without adding a lot of
> movement for the timers,

Apart from the requirement to scan empty slots - which should be quite
fast if there aren't too many of them - it should be ok provided you
restrict the granularity a bit.
Remember that the large majority of timers (esp in network code) are
'guard' timers that don't expire.

> so the red black tree should be as efficient.

I wouldn't bet on it, by far the most common timer operations are
'start' and 'stop', values are also not at all random, and removing
nodes repeatedly from one end (as timers expire) is also bad.
This means that the rb-tree is likely to be continually doing rebalance
operations.

A 'heap' (where the 'first' node) appears at the root would be better.

> Initial benchmarks from rmind@ have shown a small regression for the
> MySQL benchmark,

IMHO not surprising.

> but I hope the move to dynamic timers will ultimately
> justify this.
> 
> With dynamic timers I mean to allow platforms which programmable
> one-shot timers to schedule the callouts on a more precise base.

Which isn't a good idea!

Why not look at increasing the timer resolution to (say) 1ms, but
using the 1-shot to avoid taking interrupts when nothing is waiting.

	David

-- 
David Laight: david@l8s.co.uk