Re: [PATCH RFC 0/3] Static calls

[Masami Hiramatsu]

On Fri, 9 Nov 2018 11:05:51 -0800
Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:

> 
> 
> > On Nov 9, 2018, at 10:42 AM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> > 
> > On Fri, 9 Nov 2018 10:41:37 -0600
> > Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote:
> > 
> >>> On Fri, Nov 09, 2018 at 09:21:39AM -0600, Josh Poimboeuf wrote:
> >>>> On Fri, Nov 09, 2018 at 07:16:17AM -0800, Andy Lutomirski wrote:  
> >>>>> On Thu, Nov 8, 2018 at 11:28 PM Ingo Molnar <mingo@xxxxxxxxxx> wrote:  
> >>>>> 
> >>>>> 
> >>>>> All other usecases are bonus, but it would certainly be interesting to
> >>>>> investigate the impact of using these APIs for tracing: that too is a
> >>>>> feature enabled everywhere but utilized only by a small fraction of Linux
> >>>>> users - so literally every single cycle or instruction saved or hot-path
> >>>>> shortened is a major win.  
> >>>> 
> >>>> For tracing, we'd want static_call_set_to_nop() or something like that, right?  
> >>> 
> >>> Are we talking about tracepoints?  Or ftrace?  
> >> 
> >> Since ftrace changes calls to nops, and vice versa, I assume you meant
> >> ftrace.  I don't think ftrace is a good candidate for this, as it's
> >> inherently more flexible than this API would reasonably allow.
> >> 
> > 
> > Not sure what Andy was talking about, but I'm currently implementing
> > tracepoints to use this, as tracepoints use indirect calls, and are a
> > prime candidate for static calls, as I showed in my original RFC of
> > this feature.
> > 
> > 
> 
> Indeed.
> 
> Although I had assumed that tracepoints already had appropriate jump label magic.

As far as I know, the jump label magic is for reducing the overhead when the 
tracepoint is OFF (because it can skip function parameter preparation), and this
static call will be good when the tracepoint is ON (enabled) because of this can
avoid retpoline performance degradation.

Thank you,


-- 
Masami Hiramatsu <mhiramat@xxxxxxxxxx>