[PATCH] perf: Prevent buildid collection running forever

[PATCH] perf: Prevent buildid collection running forever

[Thomas Gleixner]

Collecting the buildids after a long perf run can result in running
forever.

The reason is that the perf_ops which buildids uses are not having the
.comm function set. Sounds weird, but the way how perf fork/mmap
handling works explains it:

On fork the new task in perf userspace inherits the registered memory
maps of the parent. This is almost correct (it's ignoring
MADV_DONTFORK) for threads and forks. For new processes the extra
"comm" event is generated which then removes the parent mappings from
the child. The buildid code ignores the comm event and therefor the
parents mappings are kept. When tracing e.g. a kernel compile then the
inherited process chain can be pretty long and every child gets the
old and partially replaced mappings of the various ancestors, which
leads to an endless shuffling in map_groups__fixup_overlappings()

Add the default comm event for now to "fix" this.

The real fix is to transport this information at clone/fork time with
the event, which is easy as the kernel knows it already. That would
avoid that whole inherit/clone/remove heuristics in the postprocessing
tools.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 tools/perf/util/build-id.c |    1 +
 1 file changed, 1 insertion(+)

Index: linux-2.6-tip/tools/perf/util/build-id.c
===================================================================
--- linux-2.6-tip.orig/tools/perf/util/build-id.c
+++ linux-2.6-tip/tools/perf/util/build-id.c
@@ -53,6 +53,7 @@ static int event__exit_del_thread(event_
 
 struct perf_event_ops build_id__mark_dso_hit_ops = {
 	.sample	= build_id__mark_dso_hit,
+	.comm	= event__process_comm,
 	.mmap	= event__process_mmap,
 	.fork	= event__process_task,
 	.exit	= event__exit_del_thread,

Re: [PATCH] perf: Prevent buildid collection running forever

[Thomas Gleixner]

On Thu, 2 Dec 2010, Thomas Gleixner wrote:

> Collecting the buildids after a long perf run can result in running
> forever.
> 
> The reason is that the perf_ops which buildids uses are not having the
> .comm function set. Sounds weird, but the way how perf fork/mmap
> handling works explains it:
> 
> On fork the new task in perf userspace inherits the registered memory
> maps of the parent. This is almost correct (it's ignoring
> MADV_DONTFORK) for threads and forks. For new processes the extra
> "comm" event is generated which then removes the parent mappings from
> the child. The buildid code ignores the comm event and therefor the
> parents mappings are kept. When tracing e.g. a kernel compile then the
> inherited process chain can be pretty long and every child gets the
> old and partially replaced mappings of the various ancestors, which
> leads to an endless shuffling in map_groups__fixup_overlappings()
> 
> Add the default comm event for now to "fix" this.

<REMOVE THIS>

> The real fix is to transport this information at clone/fork time with
> the event, which is easy as the kernel knows it already. That would
> avoid that whole inherit/clone/remove heuristics in the postprocessing
> tools.

</REMOVE THIS>

Gah. I confused myself. Grr. commit 4385d580f2 explains the magic, but
we really should have done the explicit PERF_RECORD_EXEC or at least
made the .comm thing mandatory.

It's so fricking non obvious that the map flush happens in
thread__set_comm(). 

Yours grumpy

      tglx