From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964867AbbC0ODc (ORCPT ); Fri, 27 Mar 2015 10:03:32 -0400 Received: from mail-ie0-f174.google.com ([209.85.223.174]:34018 "EHLO mail-ie0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964785AbbC0ODa (ORCPT ); Fri, 27 Mar 2015 10:03:30 -0400 Message-ID: <55156330.9080607@gmail.com> Date: Fri, 27 Mar 2015 08:03:28 -0600 From: David Ahern User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Don Zickus , acme@kernel.org CC: linux-kernel@vger.kernel.org, Joe Mario , Jiri Olsa Subject: Re: [PATCH v2] perf tool: Fix ppid for synthesized fork events 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> In-Reply-To: <20150327131005.GA162412@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/27/15 7:10 AM, Don Zickus wrote: > I talked with Joe on my way out the door yesterday and he confirmed, just > removing -BN from our test showed a performance hit with your patch. With > the -BN option, there is no performance hit and we are perfectly fine with > your patch. > > So, I guess I am confused how the -BN and your patch could change behaviour. I am too. This change has nothing to do with buildid's and scanning the buildid code setting the ppid correctly should not cause any extra work. Arnaldo: any thoughts? > > Just to re-iterate what we did, Joe kicked off a specJBB run and he did 20 > captures of two runs (one with the unpatched binary and one with a pached > binary). > > for i in {1..20} > do > time perf.unpatched mem record -a -e cpu/mem-loads,ldlat=50/pp -e cpu/mem-stores/pp sleep 10 > time perf.patched mem record -a -e cpu/mem-loads,ldlat=50/pp -e cpu/mem-stores/pp sleep 10 > done > > then we repeat the above test but with -BN in both runs. We compare the > log sizes to make sure they are similar for the random snapshots and compare > the times. With the -BN option, the times are generally within +/- 0.5 > seconds of each. Without the -BN option the patched perf binary is > generally +20-40 seconds slower. > > > > However, based on your description above about what the -BN option does, I > am scratching my head about our results. Thoughts? 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. David