Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751497AbdGRLPA (ORCPT ); Tue, 18 Jul 2017 07:15:00 -0400 Received: from mga04.intel.com ([192.55.52.120]:35735 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751403AbdGRLO7 (ORCPT ); Tue, 18 Jul 2017 07:14:59 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,377,1496127600"; d="scan'208";a="994251714" From: Alexander Shishkin To: Vince Weaver , linux-kernel@vger.kernel.org Cc: Ingo Molnar , Peter Zijlstra , Stephane Eranian Subject: Re: perf: bisected sampling bug in Linux 4.11-rc1 In-Reply-To: References: User-Agent: Notmuch/0.23.7 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Tue, 18 Jul 2017 14:08:34 +0300 Message-ID: <87lgnmvw7h.fsf@ashishki-desk.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3118 Lines: 83 Vince Weaver writes: > I was tracking down some regressions in my perf_event_test testsuite. > Some of the tests broke in the 4.11-rc1 timeframe. > > I've bisected one of them, this report is about > tests/overflow/simul_oneshot_group_overflow > This test creates an event group containing two sampling events, set > to overflow to a signal handler (which disables and then refreshes the > event). > > On a good kernel you get the following: > Event perf::instructions with period 1000000 > Event perf::instructions with period 2000000 > fd 3 overflows: 946 (perf::instructions/1000000) > fd 4 overflows: 473 (perf::instructions/2000000) > Ending counts: > Count 0: 946379875 > Count 1: 946365218 > > With the broken kernels you get: > Event perf::instructions with period 1000000 > Event perf::instructions with period 2000000 > fd 3 overflows: 938 (perf::instructions/1000000) > fd 4 overflows: 318 (perf::instructions/2000000) > Ending counts: > Count 0: 946373080 > Count 1: 653373058 > > > 487f05e18aa4efacee6357480f293a5afe6593b5 is the first bad commit > > commit 487f05e18aa4efacee6357480f293a5afe6593b5 > Author: Alexander Shishkin > Date: Thu Jan 19 18:43:30 2017 +0200 Ok, there was a bug there indeed. This patch should take care of it and should also be backportable in case it's stable-worthy. >From 187d67c9908cb126656c34546772089c17a8e6c5 Mon Sep 17 00:00:00 2001 From: Alexander Shishkin Date: Tue, 18 Jul 2017 13:53:01 +0300 Subject: [PATCH] perf: Fix scheduling regression of pinned groups Commit 487f05e18a ("perf/core: Optimize event rescheduling on active contexts") erronously assumed that event's 'pinned' setting determines whether the event belongs to a pinned group or not, but in fact, it's the group leader's pinned state that matters. This was discovered by Vince in a test case where two instruction counters are grouped, the group leader is pinned, but the other event is not; in the regressed case the counters were off by 33% (the difference between events' periods), but should be the same within the error margin. This fixes the problem by looking at the group leader's pinning. Reported-by: Vince Weaver Signed-off-by: Alexander Shishkin Fixes: 487f05e18a ("perf/core: Optimize event rescheduling on active contexts") Cc: stable@vger.kernel.org --- kernel/events/core.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/kernel/events/core.c b/kernel/events/core.c index bc63f8db1b..1edbaf94dd 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -1451,6 +1451,13 @@ static enum event_type_t get_event_type(struct perf_event *event) lockdep_assert_held(&ctx->lock); + /* + * It's 'group type', really, because if our group leader is + * pinned, so are we. + */ + if (event->group_leader != event) + event = event->group_leader; + event_type = event->attr.pinned ? EVENT_PINNED : EVENT_FLEXIBLE; if (!ctx->task) event_type |= EVENT_CPU; -- 2.11.0