On Fri, 22 Jul 2022 23:05:19 +0200 Jiri Olsa <olsajiri@xxxxxxxxx> 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 and not for any code that's in the day to day processing of the kernel, right? -- Steve
