From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753348AbcBWQfy (ORCPT ); Tue, 23 Feb 2016 11:35:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41238 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751589AbcBWQfx (ORCPT ); Tue, 23 Feb 2016 11:35:53 -0500 Date: Tue, 23 Feb 2016 22:05:50 +0530 From: Pratyush Anand To: Jiri Olsa Cc: Peter Zijlstra , mingo@kernel.org, alexander.shishkin@linux.intel.com, eranian@google.com, linux-kernel@vger.kernel.org, vince@deater.net, dvyukov@google.com, andi@firstfloor.org, sasha.levin@oracle.com, oleg@redhat.com Subject: Re: [RFC][PATCH 4/7] perf: Fix scaling vs enable_on_exec Message-ID: <20160223163550.GC11724@dhcppc3.redhat.com> References: <20160219143743.692339502@infradead.org> <20160219144132.043429490@infradead.org> <20160223152729.GT6357@twins.programming.kicks-ass.net> <20160223154849.GC9102@krava.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160223154849.GC9102@krava.redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Peter/Jiri, On 23/02/2016:04:48:49 PM, Jiri Olsa wrote: > On Tue, Feb 23, 2016 at 04:27:29PM +0100, Peter Zijlstra wrote: > > On Fri, Feb 19, 2016 at 03:37:47PM +0100, Peter Zijlstra wrote: > > > Oleg reported that enable_on_exec results in weird scale factors. > > > > > > The recent commit 3e349507d12d ("perf: Fix perf_enable_on_exec() event > > > scheduling") caused this by moving task_ctx_sched_out() from before > > > __perf_event_mask_enable() to after it. > > > > > > The overlooked concequence of that change is that task_ctx_sched_out() > > > would update the ctx time fields, and now __perf_event_mask_enable() > > > uses stale time. > > > > > > Fix this by adding an explicit time update. > > > > > > While looking at this, I also found that we need an ctx->is_active > > > check in perf_install_in_context(). > > > > > > XXX: does this actually fix the reported issue? I'm not sure what the > > > reproduction case is. Also an earlier version made Jiri's machine > > > explode -- something I've not managed to reproduce either. > > > > Jiri, can you have a look at this and perhaps share the reproducer? > > yep, I'm testing this patchset, but got stuck with 'crash' tool to get > some reasonable output.. got stuck on unrelated sched deadlock ;-) > > the reproducer is described in this email: > http://marc.info/?l=linux-kernel&m=145568006709552&w=2 > > CC-ing Pratyush Thanks for CCing. Its better with this patch, still count is 1 more in case of higher probe hits ( like 65535 times). Reproducer is: --------------------------------------------------------- git clone https://github.com/rfmvh/perftool-testsuite.git cd perftool-testsuite/base_probe/ ./setup.sh for i in 1 2 3 103 997 65535; do perf probe -x examples/exact_counts --add f_${i}x done perf stat -x';' -e 'probe_exact:*' examples/exact_counts --------------------------------------------------------- I see following with above code: 65536;;probe_exact:f_65535x;84476560;100.00 997;;probe_exact:f_997x;84476560;100.00 103;;probe_exact:f_103x;84476560;100.00 3;;probe_exact:f_3x;84476560;100.00 2;;probe_exact:f_2x;84476560;100.00 1;;probe_exact:f_1x;84476560;100.00 ~Pratyush PS: Do I need to take all patches of series? Currently I have taken only this.