2020-09-25 21:20:41

by Steven Rostedt

[permalink] [raw]
Subject: [PATCH 1/3 v2] tracepoints: Add helper to test if tracepoint is enabled in a header

From: "Steven Rostedt (VMware)" <[email protected]>

As tracepoints are discouraged from being added in a header because it can
cause side effects if other tracepoints are in headers, as well as bloat the
kernel as the trace_<tracepoint>() function is not a small inline, the common
workaround is to add a function call that calls a wrapper function in a
C file that then calls the tracepoint. But as function calls add overhead,
this function should only be called when the tracepoint in question is
enabled. To get around this overhead, a static_branch can be used to only
have the tracepoint wrapper get called when the tracepoint is enabled.

Add a tracepoint_enabled(tp) macro that gets passed the name of the
tracepoint, and this becomes a static_branch that is enabled when the
tracepoint is enabled and is a nop when the tracepoint is disabled.

Signed-off-by: Steven Rostedt (VMware) <[email protected]>
---
Documentation/trace/tracepoints.rst | 27 +++++++++++++++++++++++
include/linux/tracepoint-defs.h | 34 +++++++++++++++++++++++++++++
2 files changed, 61 insertions(+)

diff --git a/Documentation/trace/tracepoints.rst b/Documentation/trace/tracepoints.rst
index 6e3ce3bf3593..68579ebd1e4c 100644
--- a/Documentation/trace/tracepoints.rst
+++ b/Documentation/trace/tracepoints.rst
@@ -146,3 +146,30 @@ with jump labels and avoid conditional branches.
define tracepoints. Check http://lwn.net/Articles/379903,
http://lwn.net/Articles/381064 and http://lwn.net/Articles/383362
for a series of articles with more details.
+
+If you require calling a tracepoint from a header file, it is not
+recommended to call one directly or to use the trace_<tracepoint>_enabled()
+function call, as tracepoints in header files can have side effects if a
+header is included from a file that has CREATE_TRACE_POINTS set, as
+well as the trace_<tracepoint>() is not that small of an inline
+and can bloat the kernel if used by other inlined functions. Instead,
+include tracepoint-defs.h and use tracepoint_enabled().
+
+In a C file::
+
+ void do_trace_foo_bar_wrapper(args)
+ {
+ trace_foo_bar(args);
+ }
+
+In the header file::
+
+ DECLEARE_TRACEPOINT(foo_bar);
+
+ static inline void some_inline_function()
+ {
+ [..]
+ if (tracepoint_enabled(foo_bar))
+ do_trace_foo_bar_wrapper(args);
+ [..]
+ }
diff --git a/include/linux/tracepoint-defs.h b/include/linux/tracepoint-defs.h
index b29950a19205..60625973faaf 100644
--- a/include/linux/tracepoint-defs.h
+++ b/include/linux/tracepoint-defs.h
@@ -48,4 +48,38 @@ struct bpf_raw_event_map {
u32 writable_size;
} __aligned(32);

+/*
+ * If a tracepoint needs to be called from a header file, it is not
+ * recommended to call it directly, as tracepoints in header files
+ * may cause side-effects and bloat the kernel. Instead, use
+ * tracepoint_enabled() to test if the tracepoint is enabled, then if
+ * it is, call a wrapper function defined in a C file that will then
+ * call the tracepoint.
+ *
+ * For "trace_foo_bar()", you would need to create a wrapper function
+ * in a C file to call trace_foo_bar():
+ * void do_trace_foo_bar(args) { trace_foo_bar(args); }
+ * Then in the header file, declare the tracepoint:
+ * DECLARE_TRACEPOINT(foo_bar);
+ * And call your wrapper:
+ * static inline void some_inlined_function() {
+ * [..]
+ * if (tracepoint_enabled(foo_bar))
+ * do_trace_foo_bar(args);
+ * [..]
+ * }
+ *
+ * Note: tracepoint_enabled(foo_bar) is equivalent to trace_foo_bar_enabled()
+ * but is safe to have in headers, where trace_foo_bar_enabled() is not.
+ */
+#define DECLARE_TRACEPOINT(tp) \
+ extern struct tracepoint __tracepoint_##tp
+
+#ifdef CONFIG_TRACEPOINTS
+# define tracepoint_enabled(tp) \
+ static_key_false(&(__tracepoint_##tp).key)
+#else
+# define tracepoint_enabled(tracepoint) false
+#endif
+
#endif
--
2.28.0



2020-09-25 21:40:39

by Axel Rasmussen

[permalink] [raw]
Subject: Re: [PATCH 1/3 v2] tracepoints: Add helper to test if tracepoint is enabled in a header

On Fri, Sep 25, 2020 at 2:18 PM Steven Rostedt <[email protected]> wrote:
>
> From: "Steven Rostedt (VMware)" <[email protected]>
>
> As tracepoints are discouraged from being added in a header because it can
> cause side effects if other tracepoints are in headers, as well as bloat the
> kernel as the trace_<tracepoint>() function is not a small inline, the common
> workaround is to add a function call that calls a wrapper function in a
> C file that then calls the tracepoint. But as function calls add overhead,
> this function should only be called when the tracepoint in question is
> enabled. To get around this overhead, a static_branch can be used to only
> have the tracepoint wrapper get called when the tracepoint is enabled.
>
> Add a tracepoint_enabled(tp) macro that gets passed the name of the
> tracepoint, and this becomes a static_branch that is enabled when the
> tracepoint is enabled and is a nop when the tracepoint is disabled.
>
> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
> ---
> Documentation/trace/tracepoints.rst | 27 +++++++++++++++++++++++
> include/linux/tracepoint-defs.h | 34 +++++++++++++++++++++++++++++
> 2 files changed, 61 insertions(+)
>
> diff --git a/Documentation/trace/tracepoints.rst b/Documentation/trace/tracepoints.rst
> index 6e3ce3bf3593..68579ebd1e4c 100644
> --- a/Documentation/trace/tracepoints.rst
> +++ b/Documentation/trace/tracepoints.rst
> @@ -146,3 +146,30 @@ with jump labels and avoid conditional branches.
> define tracepoints. Check http://lwn.net/Articles/379903,
> http://lwn.net/Articles/381064 and http://lwn.net/Articles/383362
> for a series of articles with more details.
> +
> +If you require calling a tracepoint from a header file, it is not
> +recommended to call one directly or to use the trace_<tracepoint>_enabled()
> +function call, as tracepoints in header files can have side effects if a
> +header is included from a file that has CREATE_TRACE_POINTS set, as
> +well as the trace_<tracepoint>() is not that small of an inline
> +and can bloat the kernel if used by other inlined functions. Instead,
> +include tracepoint-defs.h and use tracepoint_enabled().
> +
> +In a C file::
> +
> + void do_trace_foo_bar_wrapper(args)
> + {
> + trace_foo_bar(args);
> + }
> +
> +In the header file::
> +
> + DECLEARE_TRACEPOINT(foo_bar);

Should be "DECLARE_..."

> +
> + static inline void some_inline_function()
> + {
> + [..]
> + if (tracepoint_enabled(foo_bar))
> + do_trace_foo_bar_wrapper(args);
> + [..]
> + }
> diff --git a/include/linux/tracepoint-defs.h b/include/linux/tracepoint-defs.h
> index b29950a19205..60625973faaf 100644
> --- a/include/linux/tracepoint-defs.h
> +++ b/include/linux/tracepoint-defs.h
> @@ -48,4 +48,38 @@ struct bpf_raw_event_map {
> u32 writable_size;
> } __aligned(32);
>
> +/*
> + * If a tracepoint needs to be called from a header file, it is not
> + * recommended to call it directly, as tracepoints in header files
> + * may cause side-effects and bloat the kernel. Instead, use
> + * tracepoint_enabled() to test if the tracepoint is enabled, then if
> + * it is, call a wrapper function defined in a C file that will then
> + * call the tracepoint.
> + *
> + * For "trace_foo_bar()", you would need to create a wrapper function
> + * in a C file to call trace_foo_bar():
> + * void do_trace_foo_bar(args) { trace_foo_bar(args); }
> + * Then in the header file, declare the tracepoint:
> + * DECLARE_TRACEPOINT(foo_bar);
> + * And call your wrapper:
> + * static inline void some_inlined_function() {
> + * [..]
> + * if (tracepoint_enabled(foo_bar))
> + * do_trace_foo_bar(args);
> + * [..]
> + * }
> + *
> + * Note: tracepoint_enabled(foo_bar) is equivalent to trace_foo_bar_enabled()
> + * but is safe to have in headers, where trace_foo_bar_enabled() is not.
> + */
> +#define DECLARE_TRACEPOINT(tp) \
> + extern struct tracepoint __tracepoint_##tp
> +
> +#ifdef CONFIG_TRACEPOINTS
> +# define tracepoint_enabled(tp) \
> + static_key_false(&(__tracepoint_##tp).key)
> +#else
> +# define tracepoint_enabled(tracepoint) false
> +#endif
> +
> #endif
> --
> 2.28.0
>
>

2020-09-25 22:03:27

by Steven Rostedt

[permalink] [raw]
Subject: Re: [PATCH 1/3 v2] tracepoints: Add helper to test if tracepoint is enabled in a header

On Fri, 25 Sep 2020 14:36:37 -0700
Axel Rasmussen <[email protected]> wrote:

> > +In a C file::
> > +
> > + void do_trace_foo_bar_wrapper(args)
> > + {
> > + trace_foo_bar(args);
> > + }
> > +
> > +In the header file::
> > +
> > + DECLEARE_TRACEPOINT(foo_bar);
>
> Should be "DECLARE_..."

But that's the British spelling!

OK, I'll go ahead and fix that in v3.

-- Steve

2020-10-20 12:01:36

by Vlastimil Babka

[permalink] [raw]
Subject: Re: [PATCH 1/3 v2] tracepoints: Add helper to test if tracepoint is enabled in a header

On 9/25/20 11:12 PM, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)" <[email protected]>
>
> As tracepoints are discouraged from being added in a header because it can
> cause side effects if other tracepoints are in headers, as well as bloat the
> kernel as the trace_<tracepoint>() function is not a small inline, the common
> workaround is to add a function call that calls a wrapper function in a
> C file that then calls the tracepoint. But as function calls add overhead,
> this function should only be called when the tracepoint in question is
> enabled. To get around this overhead, a static_branch can be used to only
> have the tracepoint wrapper get called when the tracepoint is enabled.
>
> Add a tracepoint_enabled(tp) macro that gets passed the name of the
> tracepoint, and this becomes a static_branch that is enabled when the
> tracepoint is enabled and is a nop when the tracepoint is disabled.
>
> Signed-off-by: Steven Rostedt (VMware) <[email protected]>

Nice! I'm late here, but you mentioned a v3, so FWIW:

Acked-by: Vlastimil Babka <[email protected]>

2020-10-21 18:13:03

by Steven Rostedt

[permalink] [raw]
Subject: Re: [PATCH 1/3 v2] tracepoints: Add helper to test if tracepoint is enabled in a header

On Tue, 20 Oct 2020 13:59:46 +0200
Vlastimil Babka <[email protected]> wrote:

> Nice! I'm late here, but you mentioned a v3, so FWIW:
>
> Acked-by: Vlastimil Babka <[email protected]>

You are late ;-)

afbe7973173a7ce0a68af8b33e44c967582297be

-- Steve