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

[Mathieu Desnoyers]

* 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/