[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CABPqkBQuL1-2+nFL-GZoQ4ST97kL=SgdMN4mtbY+ko4kteMvrQ@mail.gmail.com>
Date: Fri, 27 Mar 2015 08:28:43 -0700
From: Stephane Eranian <eranian@...gle.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: "Liang, Kan" <kan.liang@...el.com>,
Andi Kleen <andi@...stfloor.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] perf/x86: filter branches for PEBS event
On Fri, Mar 27, 2015 at 5:10 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> 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().
>
Ah, yes, I had forgotten about that. Then everything is fine.
>> 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.
Indeed.
--
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