Re: perf tools: Call graph from Intel BTS

[Adrian Hunter <adrian.hunter@intel.com>]

On 11/07/2014 6:18 p.m., Arnaldo Carvalho de Melo wrote:
> Em Fri, Jul 11, 2014 at 05:36:41PM +0300, Adrian Hunter escreveu:
>> There are many perf tools patches and it would be helpful to start
>> considering how to get them into mainline.  Many need to wait for
>> the driver, but others could be taken sooner.
>
> We can go on looking at each of the patches to see which ones can be
> cherry picked, i.e. the ones that are fixes and not related to the work
> you're doing, like:
>
> commit 244c87b15b124914827f3ce28d8e70c8d147c9d0
> Author: Adrian Hunter <adrian.hunter@intel.com>
> Date:   Wed Jun 11 09:33:17 2014 +0300
>
>      perf tools: Fix the value used for unknown pids
>
>      The value used for unknown pids cannot be zero
>      because that is used by the "idle" task.
>      Use -1 instead.  Also handle the unknown pid
>      case when creating map groups.
>
>      Note that, threads with an unknown pid should not
>      occur because fork (or synthesized) events precede
>      the thread's existence.
>
>      Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
>
> But then one by one they need to be reviewed to check if the changes were made
> to the whole tools/perf/ tree and if perhaps something new came along since you
> changed some assumption, like 0 meaning unknown thread, in the above patch:
>
> [acme@ssdandy linux]$ find tools -name "*.[ch]" | xargs grep machine__findnew_thread | grep 0
> tools/perf/util/session.c:	thread = machine__findnew_thread(&session->machines.host, 0, 0);

That's the idle thread.

> tools/perf/tests/thread-mg-share.c:	leader = machine__findnew_thread(machine, 0, 0);
> tools/perf/tests/thread-mg-share.c:	t1     = machine__findnew_thread(machine, 0, 1);
> tools/perf/tests/thread-mg-share.c:	t2     = machine__findnew_thread(machine, 0, 2);
> tools/perf/tests/thread-mg-share.c:	t3     = machine__findnew_thread(machine, 0, 3);

Those are valid pids for that test.

> [acme@ssdandy linux]$
>
> So I think that one way to reduce the size of that branch is to do just that:
> start fresh from tip/perf/core, and go cherry picking those patches, making sure that they
> take into account the whole current tools/perf/ tree, then ask for this patch to be pulled.
>
> You could then rebase the old branch on top of the resulting branch once it is
> merged upstream, rinse repeat.

Sounds good, thanks!  It is currently based on tip/perf/core from a few days ago, so the
current patches should be mostly ok.  I will make a selection and check them again.