Messages in this thread | | | Date | Wed, 28 Sep 2005 18:36:31 +0200 (CEST) | From | Roman Zippel <> | Subject | Re: [ANNOUNCE] ktimers subsystem |
| |
Hi,
On Tue, 27 Sep 2005, Tim Bird wrote:
> > That still means it is used and if an application > > actually depends on it, it would be penalized by > > your implementation. These timers may open up new > > application (in kernel or user space), where > > this conversion may be needed, so _only_ looking > > at the current numbers is a bit misleading. > > Oh good heavens! One can always point to real or > hypothetical cases where a change like this > will result in worse performance. Will you only > be satisfied if there is provably NO performance > degradation for ANY app on ANY platform?
I want to get the focus at the complete picture, as this is a rather critical area and I will be satisfied, as soon as I can see all consequences and possibilities have been considered.
> Even > if the code is easier to maintain, and allows > for improvements in functionality and equal or > better performance for the majority of apps. > and platforms?
If that's case, you're hopefully not afraid of a few questions? Why do I have to take the code as is and just believe the claims about it? I like improvements as everyone, but I also want to verify them and look at the alternatives and I can't see anything wrong with it.
> Unless I missed something, ktimers has not been > recommended for mainlining yet. I suspect (without > having measured it myself yet) that the > core abstraction that it proposes (timers > vs. timeouts) is an important one for improving > the kernel timing system.
I'm not saying that the idea is wrong, the general direction is fine, but some course correction should be possible?
bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |