Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751426AbVI1QhL (ORCPT ); Wed, 28 Sep 2005 12:37:11 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751432AbVI1QhL (ORCPT ); Wed, 28 Sep 2005 12:37:11 -0400 Received: from scrub.xs4all.nl ([194.109.195.176]:21479 "EHLO scrub.xs4all.nl") by vger.kernel.org with ESMTP id S1751426AbVI1QhJ (ORCPT ); Wed, 28 Sep 2005 12:37:09 -0400 Date: Wed, 28 Sep 2005 18:36:31 +0200 (CEST) From: Roman Zippel X-X-Sender: roman@scrub.home To: Tim Bird cc: Thomas Gleixner , Ingo Molnar , Christopher Friesen , linux-kernel@vger.kernel.org, akpm@osdl.org, george@mvista.com, johnstul@us.ibm.com, paulmck@us.ibm.com Subject: Re: [ANNOUNCE] ktimers subsystem In-Reply-To: <4339978F.2010609@am.sony.com> Message-ID: References: <4339978F.2010609@am.sony.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1878 Lines: 48 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/