[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181121081420.GF2131@hirez.programming.kicks-ass.net>
Date: Wed, 21 Nov 2018 09:14:20 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Andi Kleen <ak@...ux.intel.com>
Cc: Kyle Huey <me@...ehuey.com>, Kan Liang <kan.liang@...ux.intel.com>,
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
On Tue, Nov 20, 2018 at 02:38:54PM -0800, Andi Kleen wrote:
> > In fact, I'll argue FREEZE_ON_OVERFLOW is unfixably broken for
> > independent counters, because while one counter overflows, we'll stall
> > counting on all others until we've handled the PMI.
> >
> > Even though the PMI might not be for them and they very much want/need
> > to continue counting.
>
> We stop all counters in any case for the PMI. With freeze-on-PMI it just
> happens slightly earlier.
Hiding the PMI is fine and good. The PMI is not the workload. Stopping
it earlier is _NOT_ good, it hides your actual workload.
Powered by blists - more mailing lists