From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.redhat.com ([66.187.237.31]:60717 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754089AbZBUWFN (ORCPT ); Sat, 21 Feb 2009 17:05:13 -0500 Subject: Re: [PATCH] tracing/markers: make markers select tracepoints References: <499edf47.1818d00a.060b.2b8d@mx.google.com> <499EE162.4050008@oracle.com> <20090220172241.GF24538@elte.hu> <20090220173107.GH5732@nowhere> <20090220174811.GL24538@elte.hu> From: fche@redhat.com (Frank Ch. Eigler) Date: Sat, 21 Feb 2009 17:04:46 -0500 In-Reply-To: <20090220174811.GL24538@elte.hu> (Ingo Molnar's message of "Fri, 20 Feb 2009 18:48:11 +0100") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kbuild-owner@vger.kernel.org List-ID: To: Ingo Molnar Cc: Frederic Weisbecker , Avi Kivity , Randy Dunlap , Steven Rostedt , linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org Ingo Molnar writes: > [...] > there's i think the KVM usecase where markers are used > essentially a printk()-alike flexible tracing facility. > > [...] > ./vmx.c: KVMTRACE_3D(MSR_READ, vcpu, ecx, (u32)data, (u32)(data >> 32), > ./vmx.c: KVMTRACE_3D(MSR_WRITE, vcpu, ecx, (u32)data, (u32)(data >> 32), > ./vmx.c: KVMTRACE_0D(PEND_INTR, vcpu, handler); > > I think this could easily be converted to a wrapper around > ftrace_printk() plus a "kvmtrace" ftrace plugin [...] It would be even easier converted to the markers API directly, without the KVMTRACE* macro intermediary: before: KVMTRACE_3D(MSR_READ, &svm->vcpu, ecx, (u32)data, (u32)(data >> 32), handler); after: trace_mark(kvmtrace, "MSR_READ: %p, %08lx, %016Lx\n", &svm->vcpu, ecx, data); All this already "just works". The only part that's missing, from ftrace's point of view, is an interface from markers to the ftrace printing. And Lai Jiangshan kindly posted exactly such generic code back in December: http://lkml.org/lkml/2008/12/30/297 Please let's get this merged. > This means KVM tracing is activated via: > echo kvmtrace > /debug/tracing/current_tracer > that's all. Lai's interface is almost identical, and automatically works for any/all markers. > And any ad-hoc tracepoint can be added, without worrying about > the name of the macro or the number of type of arguments. [...] (This KVMTRACE stuff was always unnecessary with respect to markers, and must have been explained by some historical baggage.) - FChE