All of lore.kernel.org
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung@kernel.org>
To: Andi Kleen <andi@firstfloor.org>
Cc: jolsa@redhat.com, linux-kernel@vger.kernel.org, acme@kernel.org,
	Andi Kleen <ak@linux.intel.com>
Subject: Re: [PATCH 1/8] perf, tools: Support handling complete branch stacks as histograms
Date: Mon, 17 Nov 2014 15:23:13 +0900	[thread overview]
Message-ID: <877fyutkfi.fsf@sejong.aot.lge.com> (raw)
In-Reply-To: <20141111233153.GK12538@two.firstfloor.org> (Andi Kleen's message of "Wed, 12 Nov 2014 00:31:53 +0100")

Hi Andi,

On Wed, 12 Nov 2014 00:31:53 +0100, Andi Kleen wrote:
> Sorry for the long delay. Just revisiting that.
>
> On Wed, Oct 22, 2014 at 10:03:51AM +0900, Namhyung Kim wrote:
>> >             |          |          f2 tcall.c:5
>> >             |          |          f1 tcall.c:12
>> >             |          |          f1 tcall.c:12
>> >             |          |          f2 tcall.c:7
>> >             |          |          f2 tcall.c:5
>> >             |          |          f1 tcall.c:11
>> 
>> I think it'd be better if it just prints function names as normal
>> callchain does (and optionally srcline with a switch) and duplicates
>> removed like below:
>> 
>>      54.91%  tcall.c:6  [.] f2                      tcall
>>              |
>>              |--65.53%-- f2 tcall.c:5
>>              |          |
>>              |          |--70.83%-- f1
>>              |          |          main
>>              |          |          f1
>>              |          |          f2
>>              |          |          f1
>>              |          |          f2
>
> I considered this. For this example it doesn't make much difference
> because the functions are so small.
>
> But for anything larger I really need the line numbers to make
> sense of it. 
>
> So I prefer to keep them. I'll look into some easy switch
> to turn them off though.

Oh, I'm not just removing line numbers - it also removed duplicates (f1
and f2).  But having both from/to entries, I'm not sure it's worth tho..


>
>
>> > +		if (sort__has_parent && !*parent &&
>> > +		    symbol__match_regex(al.sym, &parent_regex))
>> > +			*parent = al.sym;
>> > +		else if (have_ignore_callees && root_al &&
>> > +		  symbol__match_regex(al.sym, &ignore_callees_regex)) {
>> > +			/* Treat this symbol as the root,
>> > +			   forgetting its callees. */
>> > +			*root_al = al;
>> > +			callchain_cursor_reset(&callchain_cursor);
>> > +		}
>> > +		if (!symbol_conf.use_callchain)
>> > +			return -EINVAL;
>> 
>> This check already went away.
>> 
>> And, to remove duplicates, I think we need to check last callchain
>> cursor node wrt the callchain_param.key here.
>
> I don't understand the comment. I'm not modifying anything
> that has been already added to the callchain. Just things
> to be added in the future. So why would I need to check
> or change the cursor?

But didn't you already do it (with ips[first_call]) to remove overlaps
between LBR and normal callchain?


>
>> 
>> Also, by comparing 'from' address, I'd expect you add the from address
>> alone but you add both of 'from' and 'to'.  Do we really need to do
>> that?
>
> Adding from and to makes it much clearer to the user what happens,
> especially with conditional branches, so they can follow the 
> control flow.

But it could be confusing too - esp. when it moves from LBR to normal
callchains?  Hmm.. maybe we can print them bit differently.


>
>
>> And the first address saved in normal callchain is address of the
>> function itself so it might be 'to' you need to check if sampled before
>> any branch in a function.
>
> I'm checking against the CALL, not the target.

Yeah, but I'm afraid that it'd always fail to find a match.


>
>> 
>> > +			} else
>> > +				be[i] = branch->entries[branch->nr - i - 1];
>> > +		}
>> > +
>> > +		nr = remove_loops(be, nr);
>> > +
>> > +		for (i = 0; i < nr; i++) {
>> > +			err = add_callchain_ip(machine, thread, parent,
>> > +					       root_al,
>> > +					       -1, be[i].to);
>> > +			if (!err)
>> > +				err = add_callchain_ip(machine, thread,
>> > +						       parent, root_al,
>> > +						       -1, be[i].from);
>> > +			if (err == -EINVAL)
>> > +				break;
>> > +			if (err)
>> > +				return err;
>> > +		}
>> > +		chain_nr -= nr;
>> 
>> I'm not sure this line is needed.
>
> Without that i could exceed the limit.

What limit?

Let's say there's a callchains and LBR records below..

callchain:
  f1 <- f2 <- f3 <- f4 <- f5

LBR
  (f1<-f1) <- (f1<-f2)

So two entries are matched, we have nr = 2, first_call = 2 and chain_nr
= 5 right?  So IIUC above code will print callchains like this:

  - f1
  - f1
  - f1
  - f2
  - f3

while I expect below (with duplicates for now):

  - f1
  - f1
  - f1
  - f2
  - f3
  - f4
  - f5

Do I miss something?

Thanks,
Namhyung

  reply	other threads:[~2014-11-17  6:23 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-26 23:37 Implement lbr-as-callgraph v10 Andi Kleen
2014-09-26 23:37 ` [PATCH 1/8] perf, tools: Support handling complete branch stacks as histograms Andi Kleen
2014-10-20  7:54   ` Jiri Olsa
2014-10-20 10:10   ` Jiri Olsa
2014-10-22  1:03   ` Namhyung Kim
2014-11-11 23:31     ` Andi Kleen
2014-11-17  6:23       ` Namhyung Kim [this message]
2014-11-18  2:08         ` Andi Kleen
2014-09-26 23:37 ` [PATCH 2/8] perf, tools: Add --branch-history option to report Andi Kleen
2014-10-20  7:54   ` Jiri Olsa
2014-10-20 17:51   ` Jiri Olsa
2014-10-22  1:26   ` Namhyung Kim
2014-11-12  0:05     ` Andi Kleen
2014-11-17  6:31       ` Namhyung Kim
2014-11-18  2:01         ` Andi Kleen
2014-09-26 23:37 ` [PATCH 3/8] perf, tools: Enable printing the srcline in the history Andi Kleen
2014-10-20 17:57   ` Jiri Olsa
2014-09-26 23:37 ` [PATCH 4/8] perf, tools: Only print base source file for srcline Andi Kleen
2014-09-26 23:37 ` [PATCH 5/8] perf, tools: Support source line numbers in annotate Andi Kleen
2014-10-20 18:06   ` Jiri Olsa
2014-10-20 18:17     ` Jiri Olsa
2014-11-12  0:36     ` Andi Kleen
2014-09-26 23:37 ` [PATCH 6/8] tools, perf: Make get_srcline fall back to sym+offset Andi Kleen
2014-09-26 23:37 ` [PATCH 7/8] tools, perf: Make srcline output address with -v Andi Kleen
2014-10-20 18:20   ` Jiri Olsa
2014-09-26 23:37 ` [PATCH 8/8] tools, perf: Add asprintf replacement Andi Kleen
2014-10-20 18:28   ` Jiri Olsa
2014-10-20 19:13     ` Geert Uytterhoeven
2014-10-20 19:21       ` Jiri Olsa
2014-10-20 19:33         ` Geert Uytterhoeven
  -- strict thread matches above, loose matches on Subject: below --
2014-09-15 23:54 Implement lbr-as-callgraph v9 Andi Kleen
2014-09-15 23:54 ` [PATCH 1/8] perf, tools: Support handling complete branch stacks as histograms Andi Kleen

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=877fyutkfi.fsf@sejong.aot.lge.com \
    --to=namhyung@kernel.org \
    --cc=acme@kernel.org \
    --cc=ak@linux.intel.com \
    --cc=andi@firstfloor.org \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.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.