Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754634AbZDXX1J (ORCPT ); Fri, 24 Apr 2009 19:27:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754398AbZDXX0i (ORCPT ); Fri, 24 Apr 2009 19:26:38 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:42430 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753983AbZDXX0h (ORCPT ); Fri, 24 Apr 2009 19:26:37 -0400 Date: Fri, 24 Apr 2009 16:20:56 -0700 From: Andrew Morton To: Frederic Weisbecker Cc: zhaolei@cn.fujitsu.com, mingo@elte.hu, kosaki.motohiro@jp.fujitsu.com, rostedt@goodmis.org, tzanussi@gmail.com, linux-kernel@vger.kernel.org, oleg@redhat.com Subject: Re: [PATCH 0/4] workqueue_tracepoint: Add worklet tracepoints for worklet lifecycle tracing Message-Id: <20090424162056.45907fef.akpm@linux-foundation.org> In-Reply-To: <20090424225909.GA6658@nowhere> References: <20090415085310.AC0D.A69D9226@jp.fujitsu.com> <20090415011533.GI5968@nowhere> <20090415141250.AC46.A69D9226@jp.fujitsu.com> <49E8282A.6010004@cn.fujitsu.com> <49E82CA7.2040606@cn.fujitsu.com> <20090417134557.GA23493@elte.hu> <49F1A59B.3080206@cn.fujitsu.com> <20090424130616.a3c217cb.akpm@linux-foundation.org> <20090424225909.GA6658@nowhere> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.20; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1264 Lines: 35 On Sat, 25 Apr 2009 00:59:10 +0200 Frederic Weisbecker wrote: > > [useful info] > OK, thanks. It was waaaay more useful than the original description. > So this latest patchset provides all these required informations on the events > tracing level. Well.. required by who? I don't recall ever seeing any problems of this nature, nor patches to solve any such problems. If someone wants to get down and optimise our use of workqueues then good for them, but that exercise doesn't require the permanent addition of large amounts of code to the kernel. The same amount of additional code and additional churn could be added to probably tens of core kernel subsystems, but what _point_ is there to all this? Who is using it, what problems are they solving? We keep on adding all these fancy debug gizmos to the core kernel which look like they will be used by one person, once. If that! > The next step is likely to be on the stat tracing to provide the avg/max time > of execution. eek. -- 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/