The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <compudj@krystal.dyndns.org>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Theodore Tso <tytso@mit.edu>,
	Arjan van de Ven <arjan@infradead.org>,
	Christoph Hellwig <hch@lst.de>,
	Lai Jiangshan <laijs@cn.fujitsu.com>,
	Zhaolei <zhaolei@cn.fujitsu.com>, Li Zefan <lizf@cn.fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Masami Hiramatsu <mhiramat@redhat.com>,
	"Frank Ch. Eigler" <fche@elastic.org>,
	Tom Zanussi <tzanussi@gmail.com>,
	Jiaying Zhang <jiayingz@google.com>,
	Michael Rubin <mrubin@google.com>,
	Martin Bligh <mbligh@google.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Neil Horman <nhorman@tuxdriver.com>,
	Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>,
	Pekka Enberg <penberg@cs.helsinki.fi>
Subject: [PATCH] tracepoints : let subsystem nop-out the tracepoints at build time
Date: Thu, 16 Apr 2009 23:05:30 -0400	[thread overview]
Message-ID: <20090417030530.GB26612@Krystal> (raw)
In-Reply-To: <49E7D0BC.4070700@goop.org>

* Jeremy Fitzhardinge (jeremy@goop.org) wrote:
> Mathieu Desnoyers wrote:
>> "all this code" is actually :
>>
>>                rcu_read_lock_sched_notrace();                          \
>>                 it_func = rcu_dereference((tp)->funcs);                 \
>>                 if (it_func) {                                          \
>>                         do {                                            \
>>                                 ((void(*)(proto))(*it_func))(args);     \
>>                         } while (*(++it_func));                         \
>>                 }                                                       \
>>                 rcu_read_unlock_sched_notrace();                        \
>>
>> Which does nothing more than disabling preemption and a for loop to
>> call all the tracepoint handlers. I don't see the big win in laying out
>> the stack to call this code out-of-line; we would just remove the
>> preempt disable and the loop, which are minimal compared to most
>> call stacks.
>>   
>
> Well, look at it from my perspective:  Ingo has been repeatedly beating  
> me up for the overhead pvops adds to a native kernel, where it really is  
> just a (direct) function call.  I want to instrument each pvop site with  
> a tracepoint so I can actually work out which calls are being called how  
> frequently to look for new optimisation opportunities.
>
> I would guess the tracepoint code sequence is going to increase the  
> impact of each pvop call site by a fair bit, and that's not counting the  
> effects the extra register pressure will have.  That's a pile of code to  
> add.
>
> And frankly, that's fine by me, because I would expect this degree of  
> introspection to have some performance hit.  But it does make the need  
> for per-subsystem tracing Kconfig entries fairly important, because I  
> don't think this would be acceptable to ship in a non-debug-everything  
> kernel build, even though other tracepoints might be.
>

Agreed. Tracepoints might change the code surrounding the pvops in a
similar fashion as the pvops themselves would change the code.
Therefore, it makes sense to have a Kconfig option to enable the pvops
tracepoints.

In terms of tracepoints (with the DECLARE_TRACE/DEFINE_TRACE semantic),
we could have something like :

in include/trace/pvops.h :

#include <linux/tracepoint.h>

#ifdef CONFIG_PVOPS_TRACEPOINTS

#define DECLARE_PVOPS_TRACE			DECLARE_TRACE
#define DEFINE_PVOPS_TRACE			DEFINE_TRACE
#define EXPORT_PVOPS_TRACEPOINT_SYMBOL_GPL	EXPORT_TRACEPOINT_SYMBOL_GPL
#define EXPORT_PVOPS_TRACEPOINT_SYMBOL		EXPORT_TRACEPOINT_SYMBOL

#else /* !CONFIG_PVOPS_TRACEPOINTS */

#define DECLARE_PVOPS_TRACE			DECLARE_TRACE_NOP
#define DEFINE_PVOPS_TRACE			DEFINE_TRACE_NOP
#define EXPORT_PVOPS_TRACEPOINT_SYMBOL_GPL	EXPORT_TRACEPOINT_SYMBOL_GPL_NOP
#define EXPORT_PVOPS_TRACEPOINT_SYMBOL		EXPORT_TRACEPOINT_SYMBOL_NOP

#endif /* CONFIG_PVOPS_TRACEPOINTS */

And then do the declarations/definitions using the new

DECLARE_PVOPS_TRACE / DEFINE_PVOPS_TRACE.

For that you'll need the patch I am attaching below. I'll let Steven
figure out how to tweak TRACE_EVENT() to support this new tracepoint
feature.

>> So basically, tracepoints are already just doing a function call, with a
>> few more bytes for preempt disable and multiple handler support.
>>
>> About the compiler deciding to put the unlikely branch out-of-line, I've
>> never seen any function calls generated just for the sake of saving
>> those few bytes, that would be crazy of the part of the compiler.
>> However, it can (and should) freely put the stack setup in the coldest
>> cache-lines possible, which are reachable by a near jump.
>>   
>
> No, it wouldn't generate a call.  But if its going to put the code out  
> of line into cold cache-lines, then it may as well generate a call.
>

Jumping out-of-line was somewhat faster than calling a function if I
recall well my performance tests. But that's all been done long ago.

And note that whenever the tracer becomes active, the out-of-line code
of busy tracepoints becomes cache-hot, which means that there is no more
cache line fetch to perform, which leaves the stack setup and other
overhead of function call/return vs 2*jump very measurable.

> Anyway, the important point from my perspective is that tracepoint.h  
> have no #include dependencies beyond linux/types.h (compiler.h, etc).
>

Is preempt.h a problem ?

Here is the patch.

Mathieu


tracepoints : let subsystem nop-out the tracepoints at build time

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
CC: Jeremy Fitzhardinge <jeremy@goop.org>
CC: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
CC: Steven Rostedt <rostedt@goodmis.org>
CC: Ingo Molnar <mingo@elte.hu>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Christoph Hellwig <hch@lst.de>
---
 include/linux/tracepoint.h |   38 ++++++++++++++++++++++----------------
 1 file changed, 22 insertions(+), 16 deletions(-)

Index: linux.trees.git/include/linux/tracepoint.h
===================================================================
--- linux.trees.git.orig/include/linux/tracepoint.h	2009-04-16 22:40:26.000000000 -0400
+++ linux.trees.git/include/linux/tracepoint.h	2009-04-16 22:40:33.000000000 -0400
@@ -37,6 +37,24 @@ struct tracepoint {
 #define TP_PROTO(args...)	args
 #define TP_ARGS(args...)		args
 
+#define DECLARE_TRACE_NOP(name, proto, args)				\
+	static inline void _do_trace_##name(struct tracepoint *tp, proto) \
+	{ }								\
+	static inline void trace_##name(proto)				\
+	{ }								\
+	static inline int register_trace_##name(void (*probe)(proto))	\
+	{								\
+		return -ENOSYS;						\
+	}								\
+	static inline int unregister_trace_##name(void (*probe)(proto))	\
+	{								\
+		return -ENOSYS;						\
+	}
+
+#define DEFINE_TRACE_NOP(name)
+#define EXPORT_TRACEPOINT_SYMBOL_GPL_NOP(name)
+#define EXPORT_TRACEPOINT_SYMBOL_NOP(name)
+
 #ifdef CONFIG_TRACEPOINTS
 
 /*
@@ -95,23 +113,11 @@ extern void tracepoint_update_probe_rang
 	struct tracepoint *end);
 
 #else /* !CONFIG_TRACEPOINTS */
-#define DECLARE_TRACE(name, proto, args)				\
-	static inline void _do_trace_##name(struct tracepoint *tp, proto) \
-	{ }								\
-	static inline void trace_##name(proto)				\
-	{ }								\
-	static inline int register_trace_##name(void (*probe)(proto))	\
-	{								\
-		return -ENOSYS;						\
-	}								\
-	static inline int unregister_trace_##name(void (*probe)(proto))	\
-	{								\
-		return -ENOSYS;						\
-	}
 
-#define DEFINE_TRACE(name)
-#define EXPORT_TRACEPOINT_SYMBOL_GPL(name)
-#define EXPORT_TRACEPOINT_SYMBOL(name)
+#define DECLARE_TRACE			DECLARE_TRACE_NOP
+#define DEFINE_TRACE			DEFINE_TRACE_NOP
+#define EXPORT_TRACEPOINT_SYMBOL_GPL	EXPORT_TRACEPOINT_SYMBOL_GPL_NOP
+#define EXPORT_TRACEPOINT_SYMBOL	EXPORT_TRACEPOINT_SYMBOL_NOP
 
 static inline void tracepoint_update_probe_range(struct tracepoint *begin,
 	struct tracepoint *end)


-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

  reply	other threads:[~2009-04-17  3:05 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-14 17:23 [PATCH 0/8] [GIT PULL] TRACE_EVENT for modules Steven Rostedt
2009-04-14 17:23 ` [PATCH 1/8] tracing: consolidate trace and trace_event headers Steven Rostedt
2009-04-14 21:51   ` Frederic Weisbecker
2009-04-14 22:04     ` Steven Rostedt
2009-04-14 17:23 ` [PATCH 2/8] tracing: create automated trace defines Steven Rostedt
2009-04-14 23:44   ` Jeremy Fitzhardinge
2009-04-15  1:45     ` Mathieu Desnoyers
2009-04-15 16:07       ` Jeremy Fitzhardinge
2009-04-16  2:34         ` Mathieu Desnoyers
2009-04-16  2:56           ` Jeremy Fitzhardinge
2009-04-16 23:44             ` Mathieu Desnoyers
2009-04-17  0:03               ` Jeremy Fitzhardinge
2009-04-17  0:13                 ` Mathieu Desnoyers
2009-04-17  0:18                   ` Jeremy Fitzhardinge
2009-04-17  0:28                     ` Mathieu Desnoyers
2009-04-17  0:43                       ` Jeremy Fitzhardinge
2009-04-17  3:05                         ` Mathieu Desnoyers [this message]
2009-04-20  7:12               ` Andi Kleen
2009-04-21 15:51                 ` Mathieu Desnoyers
2009-04-21 17:18                   ` Jeremy Fitzhardinge
2009-04-21 17:21                     ` Steven Rostedt
2009-04-21 17:43                       ` Jeremy Fitzhardinge
2009-04-21 20:28                       ` Andi Kleen
2009-04-21 21:17                         ` Steven Rostedt
2009-04-21 21:23                           ` Frank Ch. Eigler
2009-04-21 21:33                             ` Steven Rostedt
2009-04-22  5:47                               ` Mathieu Desnoyers
2009-04-22  6:07                           ` Andi Kleen
2009-04-22  6:24                             ` Steven Rostedt
2009-04-22  7:26                               ` Andi Kleen
2009-04-15  7:04   ` Zhaolei
2009-04-14 17:23 ` [PATCH 3/8] tracing: make trace_seq operations available for core kernel Steven Rostedt
2009-04-14 19:12   ` Peter Zijlstra
2009-04-15  2:19     ` Steven Rostedt
2009-04-14 17:23 ` [PATCH 4/8] tracing/events: move declarations from trace directory to core include Steven Rostedt
2009-04-14 17:23 ` [PATCH 5/8] tracing/events: move the ftrace event tracing code to core Steven Rostedt
2009-04-14 19:23   ` Peter Zijlstra
2009-04-15  2:25     ` Steven Rostedt
2009-04-15  3:40       ` Jiaying Zhang
2009-04-14 17:23 ` [PATCH 6/8] tracing/events: convert event call sites to use a link list Steven Rostedt
2009-04-14 17:23 ` [PATCH 7/8] tracing/events: add export symbols for trace events in modules Steven Rostedt
2009-04-14 17:23 ` [PATCH 8/8] tracing/events: add support for modules to TRACE_EVENT Steven Rostedt
2009-04-15  3:22   ` Rusty Russell
2009-04-14 18:15 ` [PATCH 0/8] [GIT PULL] TRACE_EVENT for modules Ingo Molnar
2009-04-14 18:25   ` Ingo Molnar
2009-04-14 18:21 ` Ingo Molnar
2009-04-14 18:33   ` Steven Rostedt
2009-04-14 18:35     ` Ingo Molnar
2009-04-14 21:04 ` Theodore Tso
2009-04-14 21:23   ` Steven Rostedt
2009-04-14 21:59     ` Steven Rostedt
2009-04-14 21:29   ` Frank Ch. Eigler
2009-04-14 22:00     ` Steven Rostedt
2009-04-16 16:53     ` Christoph Hellwig
2009-04-14 21:48   ` Jeremy Fitzhardinge
2009-04-14 21:55     ` Steven Rostedt
2009-04-14 22:33       ` Jeremy Fitzhardinge
2009-04-15  8:29         ` Ingo Molnar
2009-04-16  2:29           ` Mathieu Desnoyers
2009-04-16 16:52   ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090417030530.GB26612@Krystal \
    --to=compudj@krystal.dyndns.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=eduard.munteanu@linux360.ro \
    --cc=fche@elastic.org \
    --cc=fweisbec@gmail.com \
    --cc=hch@lst.de \
    --cc=jeremy@goop.org \
    --cc=jiayingz@google.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=mbligh@google.com \
    --cc=mhiramat@redhat.com \
    --cc=mingo@elte.hu \
    --cc=mrubin@google.com \
    --cc=nhorman@tuxdriver.com \
    --cc=penberg@cs.helsinki.fi \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=tytso@mit.edu \
    --cc=tzanussi@gmail.com \
    --cc=zhaolei@cn.fujitsu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox