From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753306AbbCZVhd (ORCPT ); Thu, 26 Mar 2015 17:37:33 -0400 Received: from mail-ig0-f173.google.com ([209.85.213.173]:37166 "EHLO mail-ig0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753111AbbCZVhb (ORCPT ); Thu, 26 Mar 2015 17:37:31 -0400 Message-ID: <55147C19.5090302@gmail.com> Date: Thu, 26 Mar 2015 15:37:29 -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 CC: acme@kernel.org, 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> In-Reply-To: <20150326211146.GZ162412@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/26/15 3:11 PM, Don Zickus wrote: > Sorry for drawing this out. Originally the performance still seemed off. > But as we split the patch up to see where the perf impact was, the problem > seemed to have disappeared. So we are testing the original patch again. > > The only difference now is we were playing with the -BN option in perf based > on your changelog, just because we never used it before. :-) I was beyond surprised that you were measuring a 50% hit with the first patch. As mentioned in a previous response it only adds the processing of 3 additional lines to the already opened and read /proc/pid/status file. So, when I wrote this second version I wanted to make sure we are only measuring the impact of this change. The /proc/pid/status files are read on startup of the record -- before any samples are taken. The intent of '-e cpu-clock -F 1000 -- usleep 1' is to avoid any samples since we don't care about them. Really the -a should be dropped as well -- no need to open per-cpu events. -B impacts processing done at the end of the run: builin-record.c, __cmd_record(): if (!rec->no_buildid) process_buildids(rec); and -N says don't copying anything to ~/.debug. All together it tries to focus the measurement to /proc walking. > > One last test without the -BN option and if that looks fine, then we have no > objections. Again sorry for dragging this out. I will let you know > tomorrow EST. no problem; appreciate the heads up.