Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934640Ab0KQIbE (ORCPT ); Wed, 17 Nov 2010 03:31:04 -0500 Received: from mx2.mail.elte.hu ([157.181.151.9]:59286 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933427Ab0KQIbA (ORCPT ); Wed, 17 Nov 2010 03:31:00 -0500 Date: Wed, 17 Nov 2010 09:30:20 +0100 From: Ingo Molnar To: Frederic Weisbecker Cc: Darren Hart , Thomas Gleixner , LKML , Linus Torvalds , Andrew Morton , Peter Zijlstra , Steven Rostedt , Arjan van de Ven , Arnaldo Carvalho de Melo , Masami Hiramatsu , Tom Zanussi , Mathieu Desnoyers , Li Zefan , Jason Baron , "David S. Miller" , Christoph Hellwig , Pekka Enberg , Lai Jiangshan , Eric Dumazet Subject: Re: [ANNOUNCE] New utility: 'trace' Message-ID: <20101117083020.GA11336@elte.hu> References: <4CE2F747.4060406@linux.intel.com> <20101116221726.GB26243@nowhere> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101116221726.GB26243@nowhere> User-Agent: Mutt/1.5.20 (2009-08-17) X-ELTE-SpamScore: -2.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-2.0 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.5 -2.0 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3498 Lines: 101 * Frederic Weisbecker wrote: > On Tue, Nov 16, 2010 at 01:27:35PM -0800, Darren Hart wrote: > > On 11/16/2010 01:04 PM, Thomas Gleixner wrote: > >> We are pleased to announce a new tracing tool called 'trace'. > >> > > > > Hi Thomas, Ingo - Congrats and Thanks! > > > >> At this point we'd like to ask for feedback from other users of tracing tools, > >> which workflow components would you like to see in addition to what the 'trace' > >> tool is offering? > >> > >> Comments, bug reports, suggestions welcome, > > > > The first thing that comes to mind is trace_marker: > > > > echo "Test point A" > /sys/kernel/debug/tracing/trace_marker > > > > I've found this sort of markup to be useful using ftrace (with C > > equivalents embedded in the test case). Is this supported? > > > No, the trace_marker file sends trace_printk events. And trace_printk > events needs to be converted to use the unified trace event interface > (ie: implement a struct ftrace_event_call). > > This shouldn't be so hard, and there are several ways we could do this. > > An idea is to reproduce the kernel file hierarchy in a "printk" event > subsystem, but this implies to allow subsystems nesting. > > Imagine you have two trace_printk(), one in kernel/sched.c:117 > and one in kernel/time/tick-sched.c:228 > The result would be: > > $ ls /sys/kernel/debug/tracing/events/printk > > /sys/kernel/debug/tracing/events/printk: > enable filter kernel/ > > /sys/kernel/debug/tracing/events/printk/kernel: > enable filter sched.c/ time/ > > /sys/kernel/debug/tracing/events/printk/kernel/sched.c: > enable filter 117/ > > /sys/kernel/debug/tracing/events/printk/kernel/sched.c/117: > enable filter format id > > /sys/kernel/debug/tracing/events/printk/kernel/time: > enable filter tick-sched.c/ > > /sys/kernel/debug/tracing/events/printk/kernel/time/tick-sched.c: > enable filter 228/ > > /sys/kernel/debug/tracing/events/printk/kernel/time/tick-sched.c/228: > enable filter format id > > > The format would be quite easy, and only one field for the whole string (strloc). > > Not sure what to do with trace_marker. I just think we can add it as: > /sys/kernel/debug/tracing/events/printk/sys/kernel/debug/tracing/trace_marker > > <:o) > > > But may be the whole idea is just fancy and nobody will care, [...] I think it's an excellent idea, and it could also give us the framework to integrate the dynamic_printk points. > [...] and would just a simple single event in a printk subsystem, on which you can > use a kind of virtual filter: > > echo "path != kernel/whatever.c:226" > /sys/kernel/debug/tracing/events/printk/filter > > would turn on every trace_printk() but the one in the given path. > > Dunno, I like both ideas. I prefer the first one which looks to me more flexible: > could be useful to list the user his trace_printks for example and implement an > interface for him to quickly select the trace_printk he wants. I prefer the first one too. > For example I'm currently working with dozens of trace_printk() and I would be > very happy to turn some of them off half of the time. I guess we could try such a patch. If you send a prototype i'd be interested in testing it out. Thanks, Ingo -- 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/