From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752917AbbCYNYK (ORCPT ); Wed, 25 Mar 2015 09:24:10 -0400 Received: from mail.kernel.org ([198.145.29.136]:36201 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752402AbbCYNYH (ORCPT ); Wed, 25 Mar 2015 09:24:07 -0400 Date: Wed, 25 Mar 2015 10:24:05 -0300 From: Arnaldo Carvalho de Melo To: Joe Mario Cc: David Ahern , Don Zickus , linux-kernel@vger.kernel.org, Jiri Olsa Subject: Re: [PATCH] perf tool: Fix ppid for synthesized fork events Message-ID: <20150325132405.GB13759@kernel.org> References: <1426786875-18025-1-git-send-email-dsahern@gmail.com> <20150319205648.GC199787@redhat.com> <550B3A66.2030902@gmail.com> <20150324201020.GH199787@redhat.com> <5511D349.7070508@gmail.com> <5512A88A.1010608@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5512A88A.1010608@redhat.com> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Wed, Mar 25, 2015 at 08:22:34AM -0400, Joe Mario escreveu: > On 03/24/2015 05:12 PM, David Ahern wrote: > >On 3/24/15 2:10 PM, Don Zickus wrote: > >>He does this with and without the patch. The difference is usually > >>over 50% extra time with the patch for both the record timings and > >>report timings.:-( > >I find that shocking. The patch only populates ppid and ptid with a > >value read from the file that is already opened and processed. Most > >of the patch is just plumbing the value from the low level function > >that processes the status file back to synthesize_fork. > >What benchmark is this? Is it something I can download and run? if so, details? site, command, args? > Hi David: > We ran "time perf mem record -a -e cpu/mem-loads,ldlat=50/pp -e > cpu/mem-stores/pp sleep 10" on a system that was running SPECjbb2013 > in the background. There were about 10,000 java threads with about > 500 to 800 in a runnable state at any given time. We ran it on a 4 > socket x86 IVB server. So it starts when there are tons of threads in the system, for which synthezing from /proc will have to take place, without looking again at that patch, I can't think about what would be a problem :-\ > We had two perf binaries. One with your patch and one without it. > Because the benchmark doesn't always have a constant load, we ran the > above perf command in a loop alternating between the patched and > unpatched version. The elapsed wall clock times ("real" field from > time) for the perf with your patch was typically >= 50% longer than > the equivalent unpatched perf. > We can't give out a copy of the SPEC benchmark (part of the SPEC > agreement). Try to find some application (or create your own) to load > the system with lots of busy threads. Haven't tried, but head this is something that could perhaps be useful here: http://kernel.ubuntu.com/~cking/stress-ng/ - Arnaldo