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

[Arnaldo Carvalho de Melo <acme@kernel.org>]

Em Wed, Apr 22, 2015 at 08:53:14AM -0400, Steven Rostedt escreveu:
> On Tue, 21 Apr 2015 21:24:51 -0500
> Ron Rechenmacher <ron@fnal.gov> wrote:
> > I've looked at the above reference briefly and it appears that user-space
> > would be mmapping the buffer read-only. Is that correct?
> 
> Correct, but I'm sure we could still add something (if it doesn't
> already exist) to have userspace write into the buffer. Ftrace has that
> with the trace_marker file.

There is something in the works, I guess Pawell Moll (sp) was working on it, and
David Ahern (CCed) should know, David?
 
> > I've also looked at lttng and I've said before, the "start-up cost" is too high.
> 
> I'm not sure what you mean by "start-up cost". Note, I'm not actually
> talking about using userspace perf. I'm talking about using the perf
> interface directly with your program like powertop does.
> 
> > 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.

> > 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.
 
> Understand. This was my feeling with logdev. I ported it year after
> year (from '98 all the way to 2007 - when ftrace made it obsolete, I
> even ported it to the xen hypervisor!).
 
> What I learned was that something that was so useful to me could also
> be very useful for others. You got my attention. I want to understand
> why this works for you so well, and perhaps we can modify the existing
> tools to make them handle all the requirements that your TRACE tool
> does or at the minimum, have something your TRACE tool can hook into.
> 
> ftrace is the result of logdev being merged with the latency-tracer
> that was in the -rt patch. I'm not saying stop doing your thing, I'm
> asking what is different about your thing that we can make our tools
> better to do it too. Your thing is obviously beneficial to you. I'm
> guessing it can be beneficial to others outside the fermilab.
 
> > 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.
 
> Again, I did not mean to use the perf user space tool. I was wondering
> if it would be possible to have TRACE use the perf kernel interface.

Well, but then it can influence how perf works, be it in the kernel (this
userspace event insertion in the ring buffer, in the works, may be suitable
here, may be not), be it in the tooling side, where there is a strace like tool
that could do parts of what you want.

- Arnaldo