Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764986AbYASE2S (ORCPT ); Fri, 18 Jan 2008 23:28:18 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757326AbYASE2L (ORCPT ); Fri, 18 Jan 2008 23:28:11 -0500 Received: from mx1.redhat.com ([66.187.233.31]:53574 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756454AbYASE2K (ORCPT ); Fri, 18 Jan 2008 23:28:10 -0500 Date: Fri, 18 Jan 2008 23:23:52 -0500 From: "Frank Ch. Eigler" To: Steven Rostedt Cc: "Frank Ch. Eigler" , Mathieu Desnoyers , LKML , Ingo Molnar , Linus Torvalds , Andrew Morton , Peter Zijlstra , Christoph Hellwig , Gregory Haskins , Arnaldo Carvalho de Melo , Thomas Gleixner , Tim Bird , Sam Ravnborg , Steven Rostedt , Paul Mackerras , Daniel Walker Subject: Re: [RFC PATCH 16/22 -v2] add get_monotonic_cycles Message-ID: <20080119042352.GF27193@redhat.com> References: <20080116201713.GA14336@Krystal> <20080117203740.GA24397@redhat.com> <20080118222637.GA30900@Krystal> <20080118231928.GA5563@Krystal> <20080119033632.GE27193@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1996 Lines: 60 Hi - On Fri, Jan 18, 2008 at 10:55:27PM -0500, Steven Rostedt wrote: > [...] > > All this complexity is to be justified by keeping the raw prev/next > > pointers from being sent to a naive tracer? It seems to me way out of > > proportion. > > Damn, and I just blew away all my marker code for something like this ;-) Sorry! :-) > [...] > We have in sched.c the following marker: > trace_mark(kernel_sched_scheduler, "prev %p next %p", prev, next); Fine so far! > Then Mathieu can add in some code somewhere (or a module, or something) > ret = marker_probe_register("kernel_sched_scheduler", > "prev %p next %p", > pretty_print_sched_switch, NULL); > static void pretty_print_sched_switch(const struct marker *mdata, > void *private_data, > const char *format, ...) > { > [...] > trace_mark(kernel_pretty_print_sched_switch, > "prev_pid %d next_pid %d prev_state %ld", > prev->pid, next->pid, prev->state); > } That marker_probe_register call would need to be done only when the embedded (k_p_p_s_s) marker is actually being used. Otherwise we'd lose all the savings of a dormant sched.c marker by always calling into pretty_print_sched_switch(), whether or not the k_p_p_s_s marker was active. In any case, if the naive tracer agrees to become educated about some of these markers in the form of intermediary functions like that, they need not insist on a second hop through marker territory anyway: static void pretty_print_sched_switch(const struct marker *mdata, void *private_data, const char *format, ...) { [...] lttng_backend_trace(kernel_pretty_print_sched_switch, "prev_pid %d next_pid %d prev_state %ld", prev->pid, next->pid, prev->state); } - FChE -- 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/