From: Christoph Hellwig <hch@infradead.org>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Arnaldo Carvalho de Melo <acme@infradead.org>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: callchain sampling bug in perf?
Date: Sat, 21 Aug 2010 10:42:39 -0400 [thread overview]
Message-ID: <20100821144239.GA31202@infradead.org> (raw)
In-Reply-To: <20100821024713.GD7959@nowhere>
On Sat, Aug 21, 2010 at 04:47:14AM +0200, Frederic Weisbecker wrote:
> > I still see the same problems as with the TUI perf report with that.
> > With the -g {mode},0.0 there is nothing to expand inside the GUI for
> ^^
> you meant "without", right?
Yes, sorry.
> The following patch solves that particular problem, I'll push it to Ingo for .36
> (and -stable):
It does seem to fix the bug for some cases but not all. Default perf
report in TUI and the normal command line seem to get it right. perf
report -g flat still shows the old problem. perf report -g flat,0.0
shows callgraphs, but just as before they just show the 0.<n>
percentages.
Btw, even in normal perf report mode the numbers while they look correct
confused me a bit. The percentages before the callgraphs split are
always relative to the node above, not absolute which is rather
confusing. And even despite adding -n to the perf report command line
I only get absolute numbers for the proccesses but not the actual
callgraphs.
> > Also the flat mode is rendered incorrectly, it just adds different call
> > graphs inside a single process directly after each other instead of
> > separating them in the rendering.
>
>
> I'm not sure what you mean. The flat format is a pure dump of every callchains
> that belong to a single process (or whatever kind of histogram source...).
>
> What do you mean by separating them in the rendering?
If there are different callchains leading to the same tracepoint they
are just appened to each other with no visual indication that they are
separate callchains
next prev parent reply other threads:[~2010-08-21 14:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-15 22:53 callchain sampling bug in perf? Christoph Hellwig
2010-08-19 0:57 ` Frederic Weisbecker
[not found] ` <20100819085700.GB8782@infradead.org>
2010-08-19 15:04 ` Arnaldo Carvalho de Melo
2010-08-20 9:16 ` Christoph Hellwig
2010-08-20 19:12 ` Arnaldo Carvalho de Melo
2010-08-21 2:29 ` Frederic Weisbecker
2010-08-21 14:44 ` Christoph Hellwig
2010-08-21 2:47 ` Frederic Weisbecker
2010-08-21 14:42 ` Christoph Hellwig [this message]
2010-08-21 14:46 ` Christoph Hellwig
2010-08-22 5:20 ` Frederic Weisbecker
2010-08-22 8:11 ` Christoph Hellwig
2010-08-22 0:49 ` Frederic Weisbecker
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=20100821144239.GA31202@infradead.org \
--to=hch@infradead.org \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@infradead.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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).