From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753107AbbC0Tuo (ORCPT ); Fri, 27 Mar 2015 15:50:44 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59582 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751284AbbC0Tum (ORCPT ); Fri, 27 Mar 2015 15:50:42 -0400 Date: Fri, 27 Mar 2015 15:49:41 -0400 From: Don Zickus To: Arnaldo Carvalho de Melo Cc: David Ahern , linux-kernel@vger.kernel.org, Joe Mario , Jiri Olsa Subject: Re: [PATCH v2] perf tool: Fix ppid for synthesized fork events Message-ID: <20150327194941.GG162412@redhat.com> References: <1427302270-10178-1-git-send-email-dsahern@gmail.com> <20150325191526.GX162412@redhat.com> <551312C0.4060706@gmail.com> <20150326211146.GZ162412@redhat.com> <55147C19.5090302@gmail.com> <20150327131005.GA162412@redhat.com> <55156330.9080607@gmail.com> <20150327142036.GI21510@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150327142036.GI21510@kernel.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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