Re: [PATCH v2] perf tool: Fix ppid for synthesized fork events

[Don Zickus]

On Fri, Mar 27, 2015 at 11:20:36AM -0300, Arnaldo Carvalho de Melo wrote:
> ... which is what David is suggesting here:
>  
> > Try this:
> > perf record -o unpatched.data -g -- perf.unpatched mem record -a -e
> > cpu/mem-loads,ldlat=50/pp -e cpu/mem-stores/pp sleep 10
> > 
> > perf record -o patched.data -g -- perf.patched mem record -a -e
> > cpu/mem-loads,ldlat=50/pp -e cpu/mem-stores/pp sleep 10
> > 
> > And then compare the reports for each.
> 
> Cache effects, i.e. OS FS caches for the files accessed when doing the
> build id table could be responsible for part of the difference at some
> point, but further investigation by using 'perf record'
> patched/unpatched will give us more clues.

Alright, Joe and I poked some more and as I thought, David's patch does
something subtle which may have inadvertently undid my original patch.
Though the threading model isn't clear in my head right now.

Here is the patch I added to test a theory:

diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c
index 1c8fbc9..7ee3823 100644
--- a/tools/perf/util/thread.c
+++ b/tools/perf/util/thread.c
@@ -187,6 +187,7 @@ static int thread__clone_map_groups(struct thread *thread,
 	if (thread->pid_ == parent->pid_)
 		return 0;
 
+	printf("DON:\n");
 	/* But this one is new process, copy maps. */
 	for (i = 0; i < MAP__NR_TYPES; ++i)
 		if (map_groups__clone(thread->mg, parent->mg, i) < 0)

before David's patch, we do _not_ see any DON markers.  After David's patch
we see a 1:1 match of DON markers to the number of threads currently running
in the system.

As a result the perf record -g command David recommended showed a spike in
rb_next and map_groups__clone which is the result of the above discovery.


So the next question is, is this correct?  On the surface I would say no
because it doesn't seem like we are not being smart any more and taking
advantage of the existing thread maps created.  But I guess the idea behind
cloning is that we are.

I can't think right now what is the correct behaviour, thoughts?

Cheers,
Don

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/