Re: [ANNOUNCE] ktimers subsystem

[James Bruce <bruce@andrew.cmu.edu>]

Roman Zippel wrote:
> On Fri, 23 Sep 2005, Thomas Gleixner wrote:
>>Each network connection, each disk I/O operation arms a timeout timer to
>>cover error conditions. Increasing the load on those increases the
>>number of armed timers. At the same time this increased load keeps the
>>timers longer active as it takes more time to detect that the "good"
>>condition arrived on time.
> 
> You're still rather vague here...
> Anyway, if the amount of active timer should be a problem, there are ways 
> to avoid them. <snip>

What does this have to do with the ktimers work itself?  It's true that 
other parts of the kernel shouldn't create more timers than necessary, 
but the timer subsystem should be able to handle a lot of timers 
regardless of that.  To put it in perspective: A server doesn't run very 
efficiently with a load of 1000, and that should be avoided by proper 
application design.  Yet we still test the scheduler on such workloads, 
don't we?  It's nice to know a subsystem doesn't fall over when its 
stressed.

If you really feel timers are overused, please bring it up with the 
maintainers of *those subsystems* which are overusing it.  There's no 
point in raising the issue with Thomas since he's not responsible for 
how other people use/misuse an existing API.

Perhaps the real issue is that you feel we should police the kernel 
usage of timers, instead of moving to a more scalable implementation. 
This is one of those rare cases however where we can have cleaner, more 
modular code, barely longer than before, which is also more scalable. 
The only thing left to measure is the performance impact, but the 
authors haven't gotten that far yet.  Instead of jumping to conclusions 
now, let's wait until we have some real numbers, shall we?

Jim Bruce