Re: [PATCH][RFC] tracing: Enable tracepoints via module parameters

From: Mathieu Desnoyers
Date: Tue Mar 08 2011 - 20:17:28 EST


* Steven Rostedt (rostedt@xxxxxxxxxxx) wrote:
> On Tue, 2011-03-08 at 19:29 -0500, Mathieu Desnoyers wrote:
> > * Steven Rostedt (rostedt@xxxxxxxxxxx) wrote:
> > > On Tue, 2011-03-08 at 19:07 -0500, Mathieu Desnoyers wrote:
> > >
> > > > So what you are saying here is that modifying /etc/modprobe.d/ is the actual
> > > > interface you propose presenting to the end-users to control their tracepoints ?
> > >
> > > If you want to have them enabled on boot, sure.
> >
> > No, I'm not talking about enabling tracepoints on boot here. Let's think about a
> > basic use-case: a distro packages a tracer, and provides a "default" set of
> > tracepoints that can be enabled when tracing is needed. Therefore, these
> > tracepoints are not enabled at boot -- they are rather enabled when tracing
> > starts. Some of these tracepoints are in dynamically loaded modules. Some of
> > these modules are automatically loaded by the distro (e.g. when a USB device is
> > plugged in).
>
> What distro are we talking about? What distro provides a "default" set
> of tracepoints?

I'm afraid I cannot say, at this point, which distro I am refering to, because
that would be a little forward of me to push news before official feature
announcements.

And about the "default" tracepoints, let's mainly think about tracepoints that
would be specified from a trace control application. E.g. the user wants a type
of tracing that collects all information required to solve a category of
problem, and they get enabled automatically.

> >
> > The specific module tracepoints should therefore only be enabled when both of
> > the following conditions are true:
> >
> > A - the end-user want to trace
> > B - the module is loaded
> >
> > But it looks like hooking on modinfo will only let you unconditionally enable
> > the module tracepoints during normal system operations (even when tracing is
> > off), or not at all unless you previously load the module (which does not fit
> > with the reality of distributions automagically loading modules on demand while
> > tracing runs).
>
> Lets keep it simple please. Right now my proposal does more than what we
> currently have. Perhaps we could change the enabling to only enable if
> "tracing is on", or some /proc/sys/kernel/X flag is set.

Well, thinking a little more about it, I won't be using this way of enabling
tracepoints in my tracer, so please feel free to make it as simple as you like.
I'm just providing feedback on what the ftrace/perf end user experience will
look like and, sadly, it does not look good at all by the look of this proposal.

>
>
> > >
> > > > Maybe I am missing something, but this interface seems to lack the layer of
> > > > finish we might want to put into a user-visible API. I don't really see how
> > > > distributions can hope to automate any of this for their end-user without making
> > > > a mess of the /etc/modprobe.d/ they ship with.
> > >
> > > What distros enable tracepoints by default?
> >
> > Do you mean enable as having a probe connected, or just CONFIG_TRACEPOINTS=y ?
>
> I mean having the probe connected as distros already have
> CONFIG_TRACEPOINTS on. What was your meaning when you said "distro
> specifying a basic set of tracepoints to enable"?

I meant that distros can contain packages that are interested in a specific set
of tracepoints (views/analysis are tracepoint data consumers), so they can
specify a set of tracepoints to enable when tracing is activated.

>
>
> >
> > >
> > > If you want to enable a tracepoint on module load simply do:
> > >
> > > modprobe mymod trace_my_tracepoint=1
> > >
> > > Otherwise modify your modprobe.d directory. This is the way users have
> > > been doing module parameters for years.
> > >
> > > That's pretty simple to me.
> >
> > Everything is always so much easier when your end-user target is yourself.
> > What are users for anyway ? :-P
>
> Users are for testing code ;)
>
> But that's a good question. As I wrote this because I'm purging my inbox
> and came across Yuanhan Liu's patch set. I'm curios to what Yuanhan's
> motivation for this change was.

Yep.

Hopefully my feedback can be of some use.

Thanks,

Mathieu

--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/