From: Peter Zijlstra <peterz@infradead.org>
To: Kyle Huey <me@kylehuey.com>
Cc: Andi Kleen <ak@linux.intel.com>,
Kan Liang <kan.liang@linux.intel.com>,
Ingo Molnar <mingo@kernel.org>,
Robert O'Callahan <robert@ocallahan.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Jiri Olsa <jolsa@redhat.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Stephane Eranian <eranian@google.com>,
Thomas Gleixner <tglx@linutronix.de>,
Vince Weaver <vincent.weaver@maine.edu>,
acme@kernel.org, open list <linux-kernel@vger.kernel.org>
Subject: Re: [REGRESSION] x86, perf: counter freezing breaks rr
Date: Tue, 20 Nov 2018 18:08:42 +0100 [thread overview]
Message-ID: <20181120170842.GZ2131@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CAP045Ap6Mm+r_44YmxNbz6HWtYArg3SAFgzk4Cm_K5HRJaRG7w@mail.gmail.com>
On Tue, Nov 20, 2018 at 08:19:39AM -0800, Kyle Huey wrote:
> tl;dr: rr is currently broken on 4.20rc2, which I bisected to
> af3bdb991a5cb57c189d34aadbd3aa88995e0d9f. I further confirmed that
> booting the 4.20rc2 kernel with `disable_counter_freezing=true` allows
> rr to work.
>
> rr, a userspace record and replay debugger[0], uses the PMU interrupt
> (PMI) to stop a program during replay to inject asynchronous events
> such as signals. With perf counter freezing enabled we are reliably
> seeing perf event overcounts during replay. This behavior is easily
> demonstrated by attempting to record and replay the `alarm` test from
> rr's test suite. Through bisection I determined that [1] is the first
> bad commit, and further testing showed that booting the kernel with
> `disable_counter_freezing=true` fixes rr.
>
> This behavior has been observed on two different CPUs (a Core i7-6700K
> and a Xeon E3-1505M v5). We have no reason to believe it is limited to
> specific CPU models, this information is included only for
> completeness.
>
> Given that we're already at rc3, and that this renders rr unusable,
> we'd ask that counter freezing be disabled for the 4.20 release.
Andi, can you have a look at this?
Meanwhile, I suppose we should do something along these lines.
---
Subject: perf/x86/intel: Default disable perfmon v4 interrupt handling
Rework the 'disable_counter_freezing' __setup() parameter such that we
can explicitly enable/disable it and switch to default disabled.
To this purpose, rename the parameter to "perf_v4_pmi=" which is a much
better description and allows requiring a bool argument.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
Documentation/admin-guide/kernel-parameters.txt | 3 ++-
arch/x86/events/intel/core.c | 12 ++++++++----
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 76c82c01bf5e..ff6d1d4229e0 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -856,7 +856,8 @@
causing system reset or hang due to sending
INIT from AP to BSP.
- disable_counter_freezing [HW]
+ perf_v4_pmi= [X86,INTEL]
+ Format: <bool>
Disable Intel PMU counter freezing feature.
The feature only exists starting from
Arch Perfmon v4 (Skylake and newer).
diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 273c62e81546..af8bea9d4006 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -2306,14 +2306,18 @@ static int handle_pmi_common(struct pt_regs *regs, u64 status)
return handled;
}
-static bool disable_counter_freezing;
+static bool disable_counter_freezing = true;
static int __init intel_perf_counter_freezing_setup(char *s)
{
- disable_counter_freezing = true;
- pr_info("Intel PMU Counter freezing feature disabled\n");
+ bool res;
+
+ if (kstrtobool(s, &res))
+ return -EINVAL;
+
+ disable_counter_freezing = !res;
return 1;
}
-__setup("disable_counter_freezing", intel_perf_counter_freezing_setup);
+__setup("perf_v4_pmi=", intel_perf_counter_freezing_setup);
/*
* Simplified handler for Arch Perfmon v4:
next prev parent reply other threads:[~2018-11-20 17:09 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-20 16:19 [REGRESSION] x86, perf: counter freezing breaks rr Kyle Huey
2018-11-20 17:08 ` Peter Zijlstra [this message]
2018-11-20 17:59 ` [tip:perf/urgent] perf/x86/intel: Fix regression by default disabling perfmon v4 interrupt handling tip-bot for Peter Zijlstra
2018-11-20 18:20 ` [REGRESSION] x86, perf: counter freezing breaks rr Stephane Eranian
2018-11-20 19:50 ` Kyle Huey
2018-11-20 19:41 ` Andi Kleen
2018-11-20 19:54 ` Kyle Huey
2018-11-20 20:11 ` Andi Kleen
2018-11-20 20:53 ` Kyle Huey
2018-11-20 21:18 ` Andi Kleen
2018-11-20 21:46 ` Kyle Huey
2018-11-20 22:19 ` Andi Kleen
2018-11-20 21:19 ` Stephane Eranian
2018-11-20 21:34 ` Kyle Huey
2018-11-20 22:16 ` Peter Zijlstra
2018-11-20 22:25 ` Peter Zijlstra
2018-11-20 22:38 ` Andi Kleen
2018-11-21 8:14 ` Peter Zijlstra
2018-11-27 22:08 ` Kyle Huey
2018-11-27 23:36 ` Andi Kleen
2018-11-28 1:25 ` Stephane Eranian
2018-11-29 14:50 ` Liang, Kan
2018-11-29 15:35 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181120170842.GZ2131@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@kernel.org \
--cc=acme@redhat.com \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=eranian@google.com \
--cc=jolsa@redhat.com \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=me@kylehuey.com \
--cc=mingo@kernel.org \
--cc=robert@ocallahan.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=vincent.weaver@maine.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox