[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150429091305.GP5029@twins.programming.kicks-ass.net>
Date: Wed, 29 Apr 2015 11:13:05 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Andy Lutomirski <luto@...capital.net>
Cc: "Brown, Len" <len.brown@...el.com>,
Andy Lutomirski <luto@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Paul Mackerras <paulus@...ba.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>
Subject: Re: [RFC] x86, perf: Add an aperfmperf driver
On Tue, Apr 28, 2015 at 03:43:38PM -0700, Andy Lutomirski wrote:
> On Tue, Apr 28, 2015 at 3:29 PM, Brown, Len <len.brown@...el.com> wrote:
> >> Thoughts? Would it make sense at all? Did I wire it up right? This is
> >> the only PMU driver I've ever written, and it could have any number of
> >> issues.
> >
> > APERF/MPERF, as with all per-thread MSRs, must be accessed
> > from the local processor. I didn't see where this driver
> > distinguishes the CPU. Also, I assume the intent is to return
> > a snapshot, rather than sampling, yes?
>
> I think that the perf core takes care of that for us, but I'm not entirely sure.
It does indeed. The events are always created/used in either task or cpu
context, and in the case of task context they're context switched along,
which again results in strict per cpu usage.
Since this driver has no state to track nothing else is required.
--
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