Patch "perf/core: Fix scheduling regression of pinned groups" has been added to the 4.12-stable tree
Subsystems (2)
This is a note to let you know that I've just added the patch titled
perf/core: Fix scheduling regression of pinned groups
to the 4.12-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
perf-core-fix-scheduling-regression-of-pinned-groups.patch
and it can be found in the queue-4.12 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.
Quoted 1 line
From
3bda69c1c3993a2bddbae01397d12bfef6054011Mon Sep 17 00:00:00 2001
From: Alexander Shishkin <[email protected]>
Date: Tue, 18 Jul 2017 14:08:34 +0300
Subject: perf/core: Fix scheduling regression of pinned groups
From: Alexander Shishkin <[email protected]>
commit 3bda69c1c3993a2bddbae01397d12bfef6054011 upstream.
Vince Weaver reported:
Quoted 18 lines
I was tracking down some regressions in my
perf_event_testtestsuite. 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
Quoted 8 lines
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
The root cause of the bug is that the following 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 the test case described above, 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.
Fix the problem by looking at the group leader's pinning.
--- kernel/events/core.c | 7 +++++++ 1 file changed, 7 insertions(+)
kernel/events/core.c +7 -0
@@ -1456,6 +1456,13 @@ static enum event_type_t get_event_type(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 ;
Patches currently in stable-queue which might be from [email protected] are
queue-4.12/perf-core-fix-scheduling-regression-of-pinned-groups.patch queue-4.12/perf-annotate-fix-broken-arrow-at-row-0-connecting-jmp-instruction-to-its-target.patch queue-4.12/revert-perf-core-drop-kernel-samples-even-though-u-is-specified.patch