Re: [RFC] ftrace: Add support to keep some functions out of ftrace

[Jiri Olsa <olsajiri@gmail.com>]

On Fri, Jul 22, 2022 at 05:41:20PM -0400, Steven Rostedt wrote:
> On Fri, 22 Jul 2022 23:05:19 +0200
> Jiri Olsa <olsajiri@gmail.com> wrote:
> 
> > ok, I think we could use that, I'll check
> > 
> > > 
> > > But other than that, we don't need infrastructure to hide any mcount/fentry
> > > locations from ftrace. Those were add *for* ftrace.  
> > 
> > I think I understand the fentry/ftrace equivalence you see, I remember
> > the perl mcount script ;-)
> 
> It's even more than that. We worked with the compiler folks to get fentry
> for ftrace purposes (namely to speed it up, and not rely on frame
> pointers, which mcount did). fentry never existed until then. Like I said.
> fentry was created *for* ftrace. And currently it's x86 specific, as it
> relies on the calling convention that a call does both, push the return
> address onto the  stack, and jump to a function. The blr
> (branch-link-register) method is more complex, which is where the
> "patchable" work comes from.
> 
> > 
> > still I think we should be able to define function that has fentry
> > profile call and be able to manage it without ftrace
> > 
> > one other thought.. how about adding function that would allow to disable
> > function in ftrace, with existing FTRACE_FL_DISABLED or some new flag
> > 
> > that way ftrace still keeps track of it, but won't allow to use it in
> > ftrace infra
> 
> Another way is to remove it at compile time from the mcount_loc table, and
> add it to your own table. I take it, this is for bpf infrastructure code

hm, perhaps we could move it to separate object and switch off
-mrecord-mcount for it, I'll check

> and not for any code that's in the day to day processing of the kernel,
> right?

yes, it's bpf specific code

thanks,
jirka