All of lore.kernel.org
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung@kernel.org>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Jiri Olsa <jolsa@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	David Ahern <dsahern@gmail.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Subject: Re: [RFC/PATCH] perf tools: Introduce perf_thread for backtrace
Date: Tue, 24 Nov 2015 16:34:35 +0900	[thread overview]
Message-ID: <20151124073435.GD2636@sejong> (raw)
In-Reply-To: <20151123213936.GF10315@kernel.org>

On Mon, Nov 23, 2015 at 06:39:36PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Nov 20, 2015 at 03:03:03PM +0900, Namhyung Kim escreveu:
> > Backtrace is a crucial info for debugging.  And upcoming refcnt
> > tracking facility also wants to use it.
> > 
> > So instead of relying on glibc's backtrace_symbols[_fd] which misses
> > some (static) functions , use our own symbol searching mechanism.  To
> > do that, add perf_thread global variable to keep its maps and symbols.
> > 
> > The backtrace output from TUI is changed like below.  (I made a key
> > action to generate a segfault for testing):
> 
> This is a really nice use of what we have, I guess we could simplify
> things further, not having to create a struct machine, as we have just
> one thread, and we're not interested in kernel addresses, so no need for
> kmaps, etc.

Yes, I thought about it.  But as adding the perf thread to an existing
machine can affect other thread(s), I didn't do it.  Maybe we can set
the perf threads' machine pointer in a hacky way without adding the
thread into the machine, but I'd rather not doing that too because
it's fragile and current code is simple enough IMHO.


> 
> But as-is it already looks better than what we were using :-)
> 
> I'll try testing it further and will probably switch to using it if
> nobody voices any problem we haven't realised with such approach.

Thank you!
Namhyung

      reply	other threads:[~2015-11-24  7:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-20  6:03 [RFC/PATCH] perf tools: Introduce perf_thread for backtrace Namhyung Kim
2015-11-20  9:05 ` 平松雅巳 / HIRAMATU,MASAMI
2015-11-20 12:10   ` Arnaldo Carvalho de Melo
2015-11-24  7:24     ` Namhyung Kim
2015-11-20  9:29 ` Jiri Olsa
2015-11-24  7:36   ` Namhyung Kim
2015-11-23 21:39 ` Arnaldo Carvalho de Melo
2015-11-24  7:34   ` Namhyung Kim [this message]

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=20151124073435.GD2636@sejong \
    --to=namhyung@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@kernel.org \
    --cc=dsahern@gmail.com \
    --cc=fweisbec@gmail.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mingo@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.