[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181127233615.GY13936@tassilo.jf.intel.com>
Date: Tue, 27 Nov 2018 15:36:15 -0800
From: Andi Kleen <ak@...ux.intel.com>
To: Kyle Huey <me@...ehuey.com>
Cc: "Peter Zijlstra (Intel)" <peterz@...radead.org>,
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
> It does seem that FREEZE_PERFMON_ON_PMI (misnamed as it is) is of
> rather limited use (or even negative, in our case) to a counter that's
> already restricted to ring 3.
It's much faster. The PMI cost goes down dramatically.
I still the the right fix is to add an perf event opt-out and let it be
used by rr.
V3 is without counter freezing.
V4 is with counter freezing.
The value is the average cost of the PMI handler.
(lower is better)
perf options ` V3(ns) V4(ns) delta
-c 100000 1088 894 -18%
-g -c 100000 1862 1646 -12%
--call-graph lbr -c 100000 3649 3367 -8%
--c.g. dwarf -c 100000 2248 1982 -12%
-Andi
Powered by blists - more mailing lists