From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: Masami Hiramatsu <mhiramat@redhat.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Takashi Nishiie <t-nishiie@np.css.fujitsu.com>,
"'Alexey Dobriyan'" <adobriyan@gmail.com>,
"'Peter Zijlstra'" <peterz@infradead.org>,
"'Steven Rostedt'" <rostedt@goodmis.org>,
"'Frank Ch. Eigler'" <fche@redhat.com>,
"'Ingo Molnar'" <mingo@elte.hu>,
"'LKML'" <linux-kernel@vger.kernel.org>,
"'systemtap-ml'" <systemtap@sources.redhat.com>,
"'Hideo AOKI'" <haoki@redhat.com>
Subject: Re: [RFC PATCH] Kernel Tracepoints
Date: Fri, 27 Jun 2008 09:30:10 -0400 [thread overview]
Message-ID: <20080627133009.GC13751@Krystal> (raw)
In-Reply-To: <486403F0.4020801@redhat.com>
* Masami Hiramatsu (mhiramat@redhat.com) wrote:
>
> > Implementation of kernel tracepoints. Inspired from the Linux Kernel Markers.
>
> What would you think redesigning markers on tracepoints? because most of the
> logic (scaning sections, multiple probe and activation) seems very similar
> to markers.
>
We could, although markers, because they use var args, allow to put the
iteration on the multi probe array out-of-line. Tracepoints cannot
afford this and the iteration must be done at the initial call-site.
>From what I see in your proposal, it's mostly to extract the if() call()
code from the inner __trace_mark() macro and to put it in a separate
macro, am I correct ? This would make the macro more readable.
> For example, (not complete, I just thought :-))
>
> struct tracepoint {
> const char *name; /* Tracepoint name */
> DEFINE_IMV(char, state); /* Immediate value state. */
> struct tracepoint_probe_closure *multi; /* Closures */
> void * callsite_data; /* private date from call site */
> } __attribute__((aligned(8)));
>
> #define __tracepoint_block(generic, name, data, func, args)
> static const char __tpstrtab_##name[] \
> __attribute__((section("__tracepoints_strings"))) \
> = #name; \
> static struct tracepoint __tracepoint_##name \
> __attribute__((section("__tracepoints"), aligned(8))) = \
> { __tpstrtab_##name, 0, NULL, data}; \
> if (!generic) { \
> if (unlikely(imv_cond(__tracepoint_##name.state))) { \
> imv_cond_end(); \
> func(&__tracepoint_##name, args); \
> } else \
> imv_cond_end(); \
> } else { \
> if (unlikely(_imv_read(__tracepoint_##name.state))) \
> func(&__tracepoint_##name, args); \
> }
>
> struct marker {
> const char *name; /* Marker name */
> const char *format; /* Marker format string, describing the
> * variable argument list.
> */
> } __attribute__((aligned(8)));
>
> #define trace_mark(name, fmt, args...) \
> do { \
> static const char __mstrtab_##name[] \
> __attribute__((section("__markers_strings"))) \
> = #name "\0" fmt; \
> static struct marker __marker_##name \
> __attribute__((section("__markers"), aligned(8))) = \
> { __mstrtab_##name, &__mstrtab_##name[sizeof(#name)]}; \
> __tracepoint_block(1, name, __marker_##name, marker_probe_cb, args) \
> } while (0)
>
> >
[...]
> > + static inline int register_trace_##name( \
> > + void (*probe)(void *private_data, proto), \
> > + void *private_data) \
> > + { \
> > + return tracepoint_probe_register(#name, (void *)probe, \
> > + private_data); \
> > + } \
> > + static inline void unregister_trace_##name( \
> > + void (*probe)(void *private_data, proto), \
> > + void *private_data) \
> > + { \
> > + tracepoint_probe_unregister(#name, (void *)probe, \
> > + private_data); \
> > + }
>
> Out of curiousity, what the private_data is for?
>
When a probe is registered, it gives more flexibility to be able to pass
a pointer to private data associated with that probe. For instance, if a
tracer needs to register the same probe to many different tracepoints,
but having a different context associated with each, it will pass the
same function pointer with different private_data to the registration
function.
> > +
> > +extern void tracepoint_update_probe_range(struct tracepoint *begin,
> > + struct tracepoint *end);
> > +
> > +#else /* !CONFIG_TRACEPOINTS */
> > +#define DEFINE_TRACE(name, proto, args) \
> > + static inline void _do_trace_##name(struct tracepoint *tp, proto) \
> > + { } \
> > + static inline void __trace_##name(int generic, proto) \
> > + { } \
> > + static inline void trace_##name(proto) \
> > + { } \
> > + static inline void _trace_##name(proto) \
> > + { }
>
> By the way, I think you'd better add below two inlines.
>
> static inline int register_trace_##name( \
> void (*probe)(void *private_data, proto), \
> void *private_data) \
> { return -ENOSYS; }
> static inline void unregister_trace_##name( \
> void (*probe)(void *private_data, proto), \
> void *private_data) \
> { }
>
My original thought was that if tracepoints are disabled, the probe
objects should not even be built. But I can foresee that they will not
always be in separate objects, so it makes sense. Will add.
Thanks,
Mathieu
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
next prev parent reply other threads:[~2008-06-27 13:35 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-20 17:03 [RFC][Patch 2/2] markers: example of irq regular kernel markers Masami Hiramatsu
2008-06-20 17:45 ` Mathieu Desnoyers
2008-06-20 19:34 ` Masami Hiramatsu
2008-06-21 10:12 ` KOSAKI Motohiro
2008-06-21 14:36 ` Steven Rostedt
2008-06-21 14:53 ` Frank Ch. Eigler
2008-06-21 15:07 ` Steven Rostedt
2008-06-21 16:13 ` Peter Zijlstra
2008-06-21 18:02 ` Frank Ch. Eigler
2008-06-22 4:31 ` Masami Hiramatsu
2008-06-23 2:19 ` KOSAKI Motohiro
2008-06-21 19:39 ` Frank Ch. Eigler
2008-06-22 4:00 ` Masami Hiramatsu
2008-06-20 20:07 ` Peter Zijlstra
2008-06-22 17:11 ` [RFC] Tracepoint proposal Mathieu Desnoyers
2008-06-22 17:59 ` Alexey Dobriyan
2008-06-22 18:27 ` Mathieu Desnoyers
2008-06-24 0:20 ` Alexey Dobriyan
2008-06-24 4:01 ` Masami Hiramatsu
2008-06-24 7:15 ` Takashi Nishiie
2008-06-24 11:55 ` Frank Ch. Eigler
2008-06-24 16:04 ` Masami Hiramatsu
2008-06-24 16:21 ` KOSAKI Motohiro
2008-06-24 17:01 ` Masami Hiramatsu
2008-06-24 17:46 ` Mathieu Desnoyers
2008-06-25 23:52 ` [RFC PATCH] Kernel Tracepoints Mathieu Desnoyers
2008-06-26 21:02 ` Masami Hiramatsu
2008-06-27 13:14 ` Mathieu Desnoyers
2008-06-27 22:45 ` Masami Hiramatsu
2008-06-30 15:43 ` Mathieu Desnoyers
2008-06-27 13:15 ` Mathieu Desnoyers
2008-06-30 19:38 ` Masami Hiramatsu
2008-06-27 13:30 ` Mathieu Desnoyers [this message]
2008-06-27 20:58 ` Masami Hiramatsu
2008-06-30 15:40 ` Mathieu Desnoyers
2008-06-30 19:58 ` Masami Hiramatsu
2008-07-03 15:12 ` Mathieu Desnoyers
2008-07-03 18:51 ` Masami Hiramatsu
2008-06-27 13:36 ` [RFC PATCH] Kernel Tracepoints (update) Mathieu Desnoyers
2008-07-03 15:27 ` Masami Hiramatsu
2008-07-03 15:47 ` Mathieu Desnoyers
2008-07-03 18:18 ` Mathieu Desnoyers
2008-07-03 18:46 ` Masami Hiramatsu
2008-06-25 23:55 ` [RFC PATCH] Tracepoint sched probes Mathieu Desnoyers
2008-06-24 3:09 ` [RFC] Tracepoint proposal Masami Hiramatsu
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=20080627133009.GC13751@Krystal \
--to=mathieu.desnoyers@polymtl.ca \
--cc=adobriyan@gmail.com \
--cc=fche@redhat.com \
--cc=haoki@redhat.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@redhat.com \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=systemtap@sources.redhat.com \
--cc=t-nishiie@np.css.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