Re: [patch 00/43] ktimer reworked

[Andrew James Wade]

On Thursday 01 December 2005 14:08, Steven Rostedt wrote:
> On Thu, 2005-12-01 at 18:44 +0100, Roman Zippel wrote:
> > Hi,
> > 
> > On Thu, 1 Dec 2005, Russell King wrote:
> ...
> > > Hence, timers have the implication that they are _expected_ to expire.
> > > Timeouts have the implication that their expiry is an exceptional
> > > condition.
> > 
> > IOW a timeout uses a timer to implement an exceptional condition after a 
> > period of time expires.
> > 
> > > So can we stop rehashing this stupid discussion?
> > 
> > The naming isn't actually my primary concern. I want a precise definition 
> > of the expected behaviour and usage of the old and new timer system. If I 
> > had this, it would be far easier to choose a proper name.
> > E.g. I still don't know why ktimeout should be restricted to raise just 
> > "error conditions", as the name implies.
> > 
> 
> ktimeout may not need to be restricted to anything.

     But does it make sense to use it in any other circumstances? It sounds
like the rb-tree based ktimer system is suitable for the general case. So
you can have a simple rule: use ktimeout for timing out when an expected
event doesn't occur, and ktimer for everything else. Are there any
situations where you want a timer optimized for the removal case that is not
also monotonic and low-res? And are there any situations in practice other
than the "timeout" one where you'd want to use a timer wheel instead of a
rb-tree?

    It sounds to me that the ktimer should be the general case, leaving
ktimeout to be optimized for one particular case (by e.g. decreasing the
resolution to reduce cascades).

Andrew Wade
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/