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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |