linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Andy Lutomirski <luto@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Jason Baron <jbaron@akamai.com>, Jiri Kosina <jkosina@suse.cz>,
	David Laight <David.Laight@ACULAB.COM>,
	Borislav Petkov <bp@alien8.de>, Juergen Gross <jgross@suse.com>
Subject: Re: [PATCH RFC 0/3] Static calls
Date: Sun, 11 Nov 2018 23:30:55 -0600	[thread overview]
Message-ID: <20181112053055.hdcv5x7md47ehunv@treble> (raw)
In-Reply-To: <20181112050241.GB28219@gmail.com>

On Mon, Nov 12, 2018 at 06:02:41AM +0100, Ingo Molnar wrote:
> 
> * Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> 
> > On Fri, Nov 09, 2018 at 08:28:11AM +0100, Ingo Molnar wrote:
> > > > - I'm not sure about the objtool approach.  Objtool is (currently)
> > > >   x86-64 only, which means we have to use the "unoptimized" version
> > > >   everywhere else.  I may experiment with a GCC plugin instead.
> > > 
> > > I'd prefer the objtool approach. It's a pretty reliable first-principles 
> > > approach while GCC plugin would have to be replicated for Clang and any 
> > > other compilers, etc.
> > 
> > The benefit of a plugin is that we'd only need two of them: GCC and
> > Clang.  And presumably, they'd share a lot of code.
> > 
> > The prospect of porting objtool to all architectures is going to be much
> > more of a daunting task (though we are at least already considering it
> > for some arches).
> 
> Which architectures would benefit from ORC support the most?

According to my (limited and potentially flawed) knowledge, I think
arm64 would benefit the most performance-wise, whereas powerpc and s390
gains would be quite a bit less.

We may have to port objtool to arm64 anyway, for live patching.  But
that will be a lot more work than it took for Ard to write a GCC plugin.

> I really think that hard reliance on GCC plugins is foolish

Funny, I feel the same way about hard reliance on objtool :-)

> - but maybe Clang's plugin infrastructure is a guarantee that it
> remains a sane and usable interface.

Hopefully so.  If it breaks, we could always write another tool, as the
work is straightforward.  Or we could make it an objtool subcommand
which works on all arches.

> > > 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.
> > 
> > With retpolines, and with tracepoints enabled, it's definitely a major
> > win.  Steve measured an 8.9% general slowdown on hackbench caused by
> > retpolines.
> 
> How much of that slowdown is reversed?

In theory, it should reverse all of the slowdown, and actually may even
speed it up a little.  Steve is working on measuring that now.

-- 
Josh

  reply	other threads:[~2018-11-12  5:31 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-08 21:15 [PATCH RFC 0/3] Static calls Josh Poimboeuf
2018-11-08 21:15 ` [RFC PATCH 1/3] static_call: Add static call infrastructure Josh Poimboeuf
2018-11-09  9:51   ` Ard Biesheuvel
2018-11-09 14:55     ` Josh Poimboeuf
2018-11-09 13:39   ` Ard Biesheuvel
2018-11-09 15:10     ` Josh Poimboeuf
2018-11-09 15:14       ` Ard Biesheuvel
2018-11-09 17:25         ` Ard Biesheuvel
2018-11-09 17:31           ` Josh Poimboeuf
2018-11-09 17:33             ` Ard Biesheuvel
2018-11-09 17:46               ` Josh Poimboeuf
2018-11-09 17:52                 ` Ard Biesheuvel
2018-11-09 17:53                   ` Ard Biesheuvel
2018-11-09 19:03                     ` Josh Poimboeuf
2018-11-09 19:12                       ` Ard Biesheuvel
2018-11-09 17:33             ` Josh Poimboeuf
2018-11-09 18:33   ` Steven Rostedt
2018-11-09 19:35     ` Josh Poimboeuf
2018-11-09 19:57       ` Steven Rostedt
2018-11-09 20:34         ` Josh Poimboeuf
2018-11-10  5:10           ` Steven Rostedt
2018-11-10 11:58             ` Ard Biesheuvel
2018-11-10 13:09               ` Steven Rostedt
2018-11-12  3:07                 ` Josh Poimboeuf
2018-11-12  4:39                   ` Ard Biesheuvel
2018-11-12  4:56                     ` Josh Poimboeuf
2018-11-12  5:02                       ` Ard Biesheuvel
2018-11-10 11:56           ` Ard Biesheuvel
2018-11-08 21:15 ` [RFC PATCH 2/3] x86/static_call: Add x86 unoptimized static call implementation Josh Poimboeuf
2018-11-08 21:15 ` [RFC PATCH 3/3] x86/static_call: Add optimized static call implementation for 64-bit Josh Poimboeuf
2018-11-08 21:24 ` [PATCH RFC 0/3] Static calls Josh Poimboeuf
2018-11-09  7:28 ` Ingo Molnar
2018-11-09  7:50   ` Ingo Molnar
2018-11-09 13:50   ` Ard Biesheuvel
2018-11-09 15:20     ` Josh Poimboeuf
2018-11-10 23:20     ` Peter Zijlstra
2018-11-11 13:42       ` Ard Biesheuvel
2018-11-11 14:25         ` Peter Zijlstra
2018-11-09 14:45   ` Josh Poimboeuf
2018-11-12  5:02     ` Ingo Molnar
2018-11-12  5:30       ` Josh Poimboeuf [this message]
2018-11-12  9:39         ` Ard Biesheuvel
2018-11-12 22:52           ` Josh Poimboeuf
2018-11-12 17:03         ` Steven Rostedt
2018-11-12 22:56           ` Josh Poimboeuf
2018-11-12  5:34       ` Andy Lutomirski
2018-11-09 15:16   ` Andy Lutomirski
2018-11-09 15:21     ` Josh Poimboeuf
2018-11-09 16:41       ` Josh Poimboeuf
2018-11-09 18:42         ` Steven Rostedt
2018-11-09 19:05           ` Andy Lutomirski
2018-11-09 19:37             ` Steven Rostedt
2018-11-09 19:44               ` Josh Poimboeuf
2018-11-09 19:59                 ` Steven Rostedt
2018-11-09 20:36                   ` Josh Poimboeuf
2018-11-10 15:13             ` Masami Hiramatsu
2018-11-09 20:53     ` Rasmus Villemoes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181112053055.hdcv5x7md47ehunv@treble \
    --to=jpoimboe@redhat.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=ard.biesheuvel@linaro.org \
    --cc=bp@alien8.de \
    --cc=jbaron@akamai.com \
    --cc=jgross@suse.com \
    --cc=jkosina@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).