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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/