linux-kernel - Re: perf tools: Call graph from Intel BTS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 12 Jul 2014 08:33:05 +0300
From:	Adrian Hunter <adrian.hunter@...el.com>
To:	Arnaldo Carvalho de Melo <acme@...nel.org>
CC:	Jiri Olsa <jolsa@...hat.com>, Ingo Molnar <mingo@...nel.org>,
	linux-kernel@...r.kernel.org,
	Frederic Weisbecker <fweisbec@...il.com>,
	Peter Zijlstra <peterz@...radead.org>,
	David Ahern <dsahern@...il.com>,
	"Shishkin, Alexander" <alexander.shishkin@...el.com>,
	Paul Mackerras <paulus@...ba.org>,
	Namhyung Kim <namhyung@...nel.org>,
	Stephane Eranian <eranian@...gle.com>
Subject: Re: perf tools: Call graph from Intel BTS

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@...el.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@...el.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@...andy 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@...andy 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/