From: Peter Zijlstra <peterz@infradead.org>
To: Stephane Eranian <eranian@google.com>
Cc: "Liang, Kan" <kan.liang@intel.com>,
Andi Kleen <andi@firstfloor.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/1] perf/x86: filter branches for PEBS event
Date: Fri, 27 Mar 2015 13:10:52 +0100 [thread overview]
Message-ID: <20150327121052.GD23123@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <CABPqkBR1rqh7F9a0iZPTWW-GTY1+-wFrYkw8VyNDOT2czxZG2w@mail.gmail.com>
On Thu, Mar 26, 2015 at 12:40:14PM -0700, Stephane Eranian wrote:
> You are addressing one of the problems of this routine. But I think
> there is a more serious issue which is not addressed here. The
> intel_shared_regs_constraints() assumes that the associated event is
> necessarily unconstrained:
>
> __intel_shared_reg_get_constraints()
> {
> struct event_constraint *c = &emptyconstraint;
> ...
> }
emptyconstraint != unconstrained.
Note how that function only returns emptyconstraint if its rejecting the
event, otherwise it returns NULL such that we continue calling
x86_get_event_constraint().
> This is true for offcore_response, but for LBR this may not always be the case.
> I may want to use LBR on the L1D_PEND_MISS event and it would need to
> be on counter 2.
> But I believe that the current code could place it on counter 0 simply
> because you return if shared_reg_get_constraint() is successful, but
> it looks only at the LBR constraint not the event constraint. I think
> in the presence of LBR, you always need to call share_get_reg() and
> x86_get_event_constraint().
Which, I think it does.
next prev parent reply other threads:[~2015-03-27 12:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-26 18:13 [PATCH 1/1] perf/x86: filter branches for PEBS event kan.liang
2015-03-26 19:40 ` Stephane Eranian
2015-03-26 20:20 ` Liang, Kan
2015-03-26 21:02 ` Stephane Eranian
2015-03-27 12:10 ` Peter Zijlstra [this message]
2015-03-27 15:28 ` Stephane Eranian
2015-03-27 12:17 ` Peter Zijlstra
2015-03-27 13:09 ` Liang, Kan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150327121052.GD23123@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=andi@firstfloor.org \
--cc=eranian@google.com \
--cc=kan.liang@intel.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.