Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750874AbWC3FEZ (ORCPT ); Thu, 30 Mar 2006 00:04:25 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750931AbWC3FET (ORCPT ); Thu, 30 Mar 2006 00:04:19 -0500 Received: from smtp.osdl.org ([65.172.181.4]:13780 "EHLO smtp.osdl.org") by vger.kernel.org with ESMTP id S1750854AbWC3FEQ (ORCPT ); Thu, 30 Mar 2006 00:04:16 -0500 Date: Wed, 29 Mar 2006 21:03:14 -0800 From: Andrew Morton To: Shailabh Nagar Cc: greg@kroah.com, arjan@infradead.org, hadi@cyberus.ca, ak@suse.de, linux-kernel@vger.kernel.org, lse-tech@lists.sourceforge.net Subject: Re: [Patch 0/8] per-task delay accounting Message-Id: <20060329210314.3db53aaa.akpm@osdl.org> In-Reply-To: <442B271D.10208@watson.ibm.com> References: <442B271D.10208@watson.ibm.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2193 Lines: 47 Shailabh Nagar wrote: > > Could you please include the following delay accounting patches > in -mm ? I'm at a loss to evaluate the suitability of this work, really. I always am when accounting patches come along. There are various people and various groups working on various different things and there appears to be no coordination and little commonality of aims. I worry that picking one submission basically at random will provide nothing which the other groups can work on to build up their feature. On the other hand, we don't want to do nothing until some uber-grand all-singing, all-dancing statistics-gathering infrastructure comes along. So I'm a bit stuck. What I would like to see happen is that there be some coordination between the various stakeholders, and some vague plan which they're all happy with as a basis for the eventual grand solution. We already have various bits and pieces of statistics gathering in the kernel and it's already a bit ad-hoc. Adding more one-requirement-specific accounting code won't improve that situation. But then, I said all this a year or two ago and nothing much has happened since then. It's not your fault, but it's a problem. Perhaps a good starting point would be a one-page bullet-point-form wishlist of all the accounting which people want to get out of the kernel, and a description of what the kernel<->user interface should look like. Right now, I don't think we even have a picture of that. We need a statistics maintainer, too, to pull together the plan, coordinate, push things forwards. The first step would be to identify the stakeholders, come up with that page of bullet-points. Then again, maybe the right thing to do is to keep adding low-impact requirement-specific statistics patches as they come along. But if we're going to do it that way, we need an up-front reason for doing so, and I don't know what that would be. See my problem? - 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/