mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Josh Poimboeuf' <jpoimboe@redhat.com>
Cc: 'Alexei Starovoitov' <alexei.starovoitov@gmail.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"bpf@vger.kernel.org" <bpf@vger.kernel.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	Song Liu <songliubraving@fb.com>,
	"Kairui Song" <kasong@redhat.com>
Subject: RE: [PATCH 6/9] x86/bpf: Fix JIT frame pointer usage
Date: Mon, 17 Jun 2019 15:07:03 +0000	[thread overview]
Message-ID: <a1942e57ed0844fab62b6bdf0f465578@AcuMS.aculab.com> (raw)
In-Reply-To: <20190614170720.57yxtxvd4qee337l@treble>

From: Josh Poimboeuf
> Sent: 14 June 2019 18:07
...
> > I do remember a stack trace printer for x86 this didn't need
> > any annotation of the object code and didn't need frame pointers.
> > The only downside was that it had to 'guess' (ie scan the stack)
> > to get out of functions that couldn't return.
> > Basically it followed the control flow forwards tracking the
> > values of %sp and %bp until it found a return instuction.
> > All it has to do is detect loops and retry from the other
> > target of conditional branches.
> 
> That actually sounds kind of cool, though I don't think we need that for
> the kernel.

No reason why not.
It would save most of the instrumentation the orc unwinder needs.
It isn't as though the performance of kernel tracebacks is that
important (printf and symbol lookup probably always dominates).
The only difficulty for x86 is quickly determining the size of
instructions.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

  reply	other threads:[~2019-06-17 15:07 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-13 13:20 [PATCH 0/9] x86/bpf: unwinder fixes Josh Poimboeuf
2019-06-13 13:20 ` [PATCH 1/9] perf/x86: Always store regs->ip in perf_callchain_kernel() Josh Poimboeuf
2019-06-13 13:20 ` [PATCH 2/9] objtool: Fix ORC unwinding in non-JIT BPF generated code Josh Poimboeuf
2019-06-13 20:57   ` Alexei Starovoitov
2019-06-14  1:20     ` Josh Poimboeuf
2019-06-14  1:37       ` Alexei Starovoitov
2019-06-14  1:51         ` Josh Poimboeuf
2019-06-14  7:08       ` Peter Zijlstra
2019-06-14  7:35         ` Alexei Starovoitov
2019-06-14  8:11           ` Peter Zijlstra
2019-06-14 15:13             ` Alexei Starovoitov
2019-06-14 16:11               ` Josh Poimboeuf
2019-06-13 13:21 ` [PATCH 3/9] x86/bpf: Move epilogue generation to a dedicated function Josh Poimboeuf
2019-06-13 18:57   ` Song Liu
2019-06-13 19:12     ` Josh Poimboeuf
2019-06-13 13:21 ` [PATCH 4/9] x86/bpf: Simplify prologue generation Josh Poimboeuf
2019-06-13 13:21 ` [PATCH 5/9] x86/bpf: Support SIB byte generation Josh Poimboeuf
2019-06-13 13:21 ` [PATCH 6/9] x86/bpf: Fix JIT frame pointer usage Josh Poimboeuf
2019-06-13 21:58   ` Alexei Starovoitov
2019-06-14  1:22     ` Josh Poimboeuf
2019-06-14  1:39       ` Alexei Starovoitov
2019-06-14  1:52         ` Josh Poimboeuf
2019-06-14 10:50     ` David Laight
2019-06-14 13:44       ` Josh Poimboeuf
2019-06-14 13:58         ` David Laight
2019-06-14 17:07           ` Josh Poimboeuf
2019-06-17 15:07             ` David Laight [this message]
2019-06-13 13:21 ` [PATCH 7/9] x86/unwind/orc: Fall back to using frame pointers for generated code Josh Poimboeuf
2019-06-13 22:00   ` Alexei Starovoitov
2019-06-14  1:30     ` Josh Poimboeuf
2019-06-14  1:42       ` Alexei Starovoitov
2019-06-14  1:58         ` Josh Poimboeuf
2019-06-14  2:28           ` Josh Poimboeuf
2019-06-14  4:50             ` Josh Poimboeuf
2019-06-14  6:00               ` Alexei Starovoitov
2019-06-14  7:41                 ` Peter Zijlstra
2019-06-14 13:31                   ` Josh Poimboeuf
2019-06-14 15:29                   ` Alexei Starovoitov
2019-06-14 13:34                 ` Josh Poimboeuf
2019-06-14 15:31                   ` Alexei Starovoitov
2019-06-14 15:56                     ` Josh Poimboeuf
2019-06-13 13:21 ` [PATCH 8/9] x86/bpf: Convert asm comments to AT&T syntax Josh Poimboeuf
2019-06-13 18:52   ` Song Liu
2019-06-13 19:11     ` Josh Poimboeuf
2019-06-14  7:42     ` Peter Zijlstra
2019-06-14 15:13       ` Song Liu
2019-06-13 13:21 ` [PATCH 9/9] x86/bpf: Convert MOV function/macro argument ordering " Josh Poimboeuf
2019-06-13 19:00 ` [PATCH 0/9] x86/bpf: unwinder fixes Song Liu
2019-06-13 20:41 ` Peter Zijlstra

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=a1942e57ed0844fab62b6bdf0f465578@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=jpoimboe@redhat.com \
    --cc=kasong@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=songliubraving@fb.com \
    --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

Powered by JetHome