Re: [PATCH] tracing: Export key trace event symbols

[Ron Rechenmacher]

Steven Rostedt wrote on 04/21/15 17:44:
> [ Added a bunch of people that use perf ;-) ]

Thanks. I hope they can help me get the patch accepted.

[snip]
> > > +/*
> > > + * Allow modules to register additional trace routines
> > > + */
> > > +EXPORT_TRACEPOINT_SYMBOL_GPL(irq_handler_entry);
> > > +EXPORT_TRACEPOINT_SYMBOL_GPL(irq_handler_exit);
> > > +
> > >
> > > Instead of just saying "Allow modules to register additional trace
> > > routines", please explain what its used for. What are you measuring
> > > externally? Just the timings of the interrupts?
> >
> > How about "Allow for module (internal or external) to register trace function which
> > shows (or measures) interactions with user-space executables more directly.  Knowing
> > when interrupts happen and how they can subtly impact user-space application timing
> > is important in some application."
> >
> > > I'm also curious to know why ftrace isn't good enough.
> >
> > ftrace (if one considers ltt-ng) is probably capable of doing what my trace does
> > except that the timestamp is not TOD (Time Of Day) -- but probably/maybe could
> > be made to do so???
> >
> > It's a matter of complexity or "start up cost" (or entry barrier).
> >
> > I'm not the best at articulating all there is to TRACE succinctly, but lets
> > start with the fact that the user-space component of TRACE is basically just a header
> > file that defines the TRACE printf-like macro and handles the initialization which is
> > basically mmap-ing a file (as a trace buffer (with control structure)) and is,
> > for the most part, Unix OS independent.
>
> Heh, that sounds like the perf interface. Have you thought about using
> that instead?
>
> Look at what PowerTop does: https://01.org/powertop
>
> You can use the perf interface to mmap a memory buffer and read the
> data in its raw format. To parse the data, you need to read the format

I've looked at the above reference briefly and it appears that user-space
would be mmapping the buffer read-only. Is that correct?
I've also looked at lttng and I've said before, the "start-up cost" is too high.
My TRACE module creates the virtual file and allows the user-space program(s) to
mmap a portion of it read-only (to protect the kernel) and then the buffer portion
read-write - so, yes, any user-space program _could_ simply scribble over the
buffer-portion, but what they usually end up doing it _writing_ their traces into
the appropriate "slot" memory along side of slots that the kernel could be writing the
key event TRACEs to.
I'm not trying to promote the use of my TRACE, I'm just trying to show
that there is a set of valid reasons (current and potential future) for accepting my patch.

> files in /sys/kernel/debug/tracing/events, but there's a library that
> does that. Unfortunately, that library isn't in distros yet (we really
> need to get that done). But you can just copy the code from the kernel
> source tree from tools/lib/traceevents/ and use that as perf does (as
> well as powertop does too).
>
> The format files tells you how to get the data from the raw binary
> format.
>
> If you use the perf interface, you can have userspace tools do custom
> things with the events as they happen. This may make your utility more
> robust in the long run.
>
> I'd be happy to help you understand how to use the traceevent library. I
> don't use the perf interface, but you can get examples from the
> PowerTop code.

I'd rather not get into the "you should stop doing your thing and just/only do
something else" mode, if you don't mind. As I've said before, I believe my TRACEing
is just the right level of complexity for the total system analysis that I do and
I have been periodically checking/searching what's out there.

A college of mine and I actually used perf, just today, to gain an understanding
of what is going on in our "Nova data acquistion" system at fermilab. While it was
useful, it is not a replacement for TRACE.

Thanks,
Ron

> -- Steve
[snip]

--
Ron Rechenmacher
Engineer
Fermi National Accelerator Laboratory
Batavia, IL  60510
--
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/