Re: [patch 00/43] ktimer reworked

[Roman Zippel]

Hi,

On Sat, 3 Dec 2005, Andrew James Wade wrote:

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

By reducing the resolution you only reduce the frequency of the cascading, 
but the amount of timer in the timer wheel at any time is still the same.
So in general you will have less number of cascades, but not generally 
smaller cascades. The latter depends on the actual timeout value and its
distribution over the wheel. This means you can tune the resolution to 
avoid most cascading for a specific situation, but that would be a rather 
bad general solution.

rbtree based timer are also not necessarily the better general case. The 
timer wheel still scales better with O(n) compared to the rbtree with
O(n*log(n)).

It's really better to keep the focus of the new timer at high resolution 
timer, that's what it's really better at and we shouldn't try to use it 
for everything only because it has such a kool name.

bye, Roman
-
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/