Re: [PATCH] ftrace: add simple oneshot function tracer

[Thomas Preisner]

On Mon, Jun 17, 2019 at 08:16:27PM -0400, Steven Rostedt wrote:
> On Wed, 12 Jun 2019 23:29:35 +0200
> Thomas Preisner <linux@xxxxxxxxxxxx> wrote:
> 
> Hi Thomas,
> 
> BTW, what email client do you use, because your replies seem to confuse
> my email client (claws-mail) and it doesn't thread them at all.
> Although they do look fine on mutt (when I view my LKML folder). Looks
> like it doesn't create a "References:" header.
> 
> > On Tue, 11 Jun 2019 17:52:37 -0400
> > Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> > 
> > > What do you mean? The function profile has its own file to enable it:
> > > 
> > >  echo 1 > /sys/kernel/tracing/function_profile_enabled
> > >  
> > >  And disable it:
> > >  
> > >   echo 0 > /sys/kernel/tracing/function_profile_enabled
> > >   
> > >   -- Steve  
> > 
> > Yes, I am aware of the function profiler providing a file operation for
> > enabling and disabling itself. However, my oneshot profiler as of [PATCH
> > v2] is a separate tracer/profiler without this file operation.
> > 
> > As this oneshot profiler is intended to be used for coverage/usage
> > reports I want it to be able to record functions as soon as possible
> > during bootup. Therefore, I just permanently activated the oneshot
> > profiler since as of now there is no means to activate it or the
> > function profiler via kernel commandline just like the normal tracers.
> > 
> > Still, if you want to I can add the file operation for
> > enabling/disabling this new profiler together with a new kernel
> > commandline argument for this profiler?
> > 
> > Or what would be your prefered way?
> > 
> 
> Hmm, I guess I still need to think about exactly what this is for.
> Perhaps we could add a "oneshot" option to the function tracer, and
> when set it will only trace a function once? Is there a strong reason
> to add a new event type "oneshot_entry"? It may be useful to record the
> parent of the function that triggered the first instance as well.
> 
> I'm still trying to get a grip around exactly what use cases this would
> be good for. Especially when adding new functionality like this.
> 
> -- Steve
> 

I've created this tracer with kernel tailoring in mind since the
tailoring process of e.g. undertaker heavily benefits from a more
precise set of input data.

A "oneshot" option for the function tracer would be a viable
possibility. However, this may add a lot of overhead (performance wise)
in comparison to my current approach? After all, the use case of my
tracer would be some sort of kernel activity monitoring during "normal
usage" in order to get a grasp of (hopefully) all required kernel
functions.

Also, there is no strong reason to add a new event type,
this was just a means of reducing the collected data (which may as well
be omitted since there is no real benefit).

My "oneshot tracer" actually collects and outputs every parent in order
to get a more thorough view on used kernel code. Therefore, I would
suggest to keep this functionality and maybe make it configurable
instead?

Yours sincerely,
Thomas