[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150717201747.GF7380@tassilo.jf.intel.com>
Date: Fri, 17 Jul 2015 13:17:47 -0700
From: Andi Kleen <ak@...ux.intel.com>
To: Mark Rutland <mark.rutland@....com>
Cc: "kan.liang@...el.com" <kan.liang@...el.com>,
"a.p.zijlstra@...llo.nl" <a.p.zijlstra@...llo.nl>,
"mingo@...hat.com" <mingo@...hat.com>,
"acme@...nel.org" <acme@...nel.org>,
"eranian@...gle.com" <eranian@...gle.com>,
"adrian.hunter@...el.com" <adrian.hunter@...el.com>,
"dsahern@...il.com" <dsahern@...il.com>,
"jolsa@...nel.org" <jolsa@...nel.org>,
"namhyung@...nel.org" <namhyung@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/9] perf/x86: special case per-cpu core misc PMU events
> As with my earlier comments, I don't think these can be grouped with
> events (not even from the same PMU given their free-running nature).
Mark, we already went through this last time. There is nothing
stopping handling free running counters as part of other groups.
A perf event logically has a 64bit counter that accumulates counts from
a less wide hardware counter. A free running counter just has
to be sampled at the beginning and at the end of the measurement
period, and the difference between the two values added to the perf
counter. To handle CPU switches the counter is just sampled, and
accumulated into the software counter, before switching to another CPU.
Then you start the next measurement period with a sample from the
new CPU etc.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists