[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181120194129.GC13936@tassilo.jf.intel.com>
Date: Tue, 20 Nov 2018 11:41:29 -0800
From: Andi Kleen <ak@...ux.intel.com>
To: Kyle Huey <me@...ehuey.com>
Cc: Kan Liang <kan.liang@...ux.intel.com>,
"Peter Zijlstra (Intel)" <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
Robert O'Callahan <robert@...llahan.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Jiri Olsa <jolsa@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Stephane Eranian <eranian@...gle.com>,
Thomas Gleixner <tglx@...utronix.de>,
Vince Weaver <vincent.weaver@...ne.edu>, acme@...nel.org,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [REGRESSION] x86, perf: counter freezing breaks rr
> 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
It's hard to see how it could over count since the PMU freezes
earlier than the PMI with freezing. So it should count less.
Did you mean under count?
> 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.
The boot option should be good enough for the release?
A reasonable future option would be to expose an option to disable it in
the perf_event. Then rr could set it.
-Andi
Powered by blists - more mailing lists