All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Liang, Kan" <kan.liang@intel.com>
To: Stephane Eranian <eranian@google.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Andi Kleen <andi@firstfloor.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 1/1] perf/x86: filter branches for PEBS event
Date: Thu, 26 Mar 2015 20:20:53 +0000	[thread overview]
Message-ID: <37D7C6CF3E00A74B8858931C1DB2F07701778F3E@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <CABPqkBR1rqh7F9a0iZPTWW-GTY1+-wFrYkw8VyNDOT2czxZG2w@mail.gmail.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 5602 bytes --]



> Subject: Re: [PATCH 1/1] perf/x86: filter branches for PEBS event
> 
> On Thu, Mar 26, 2015 at 11:13 AM,  <kan.liang@intel.com> wrote:
> > From: Kan Liang <kan.liang@intel.com>
> >
> > For supporting Intel LBR branches filtering, Intel LBR sharing logic
> > mechanism is introduced from commit b36817e88630 ("perf/x86: Add
> Intel
> > LBR sharing logic"). It modifies __intel_shared_reg_get_constraints to
> > config lbr_sel, which is finally used to set LBR_SELECT.
> > However, the intel_shared_regs_constraints is called after
> > intel_pebs_constraints. The PEBS event will return immediately after
> > intel_pebs_constraints. So it's impossible to filter branches for PEBS
> > event.
> >
> > This patch move intel_shared_regs_constraints for branch_reg ahead of
> > intel_pebs_constraints.
> > intel_shared_regs_constraints for branch_reg doesn't modify event->hw,
> > so it's safe to be called before intel_pebs_constraints.
> > intel_shared_regs_constraints for branch_reg also special case when it
> > returns &emptyconstraint. It put constraints for extra_reg. This patch
> > remove it. Because it will never get constraints for extra_reg if
> > return is &emptyconstraint.
> >
> > Signed-off-by: Kan Liang <kan.liang@intel.com>
> > ---
> >  arch/x86/kernel/cpu/perf_event_intel.c | 34
> > ++++++++++++----------------------
> >  1 file changed, 12 insertions(+), 22 deletions(-)
> >
> > diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
> > b/arch/x86/kernel/cpu/perf_event_intel.c
> > index 9f1dd18..247780a 100644
> > --- a/arch/x86/kernel/cpu/perf_event_intel.c
> > +++ b/arch/x86/kernel/cpu/perf_event_intel.c
> > @@ -1587,25 +1587,14 @@ __intel_shared_reg_put_constraints(struct
> > cpu_hw_events *cpuc,
> >
> >  static struct event_constraint *
> >  intel_shared_regs_constraints(struct cpu_hw_events *cpuc,
> > -                             struct perf_event *event)
> > +                             struct perf_event *event,
> > +                             struct hw_perf_event_extra *reg)
> >  {
> > -       struct event_constraint *c = NULL, *d;
> > -       struct hw_perf_event_extra *xreg, *breg;
> > +       struct event_constraint *c = NULL;
> > +
> > +       if (reg->idx != EXTRA_REG_NONE)
> > +               c = __intel_shared_reg_get_constraints(cpuc, event,
> > + reg);
> >
> > -       xreg = &event->hw.extra_reg;
> > -       if (xreg->idx != EXTRA_REG_NONE) {
> > -               c = __intel_shared_reg_get_constraints(cpuc, event, xreg);
> > -               if (c == &emptyconstraint)
> > -                       return c;
> > -       }
> > -       breg = &event->hw.branch_reg;
> > -       if (breg->idx != EXTRA_REG_NONE) {
> > -               d = __intel_shared_reg_get_constraints(cpuc, event, breg);
> > -               if (d == &emptyconstraint) {
> > -                       __intel_shared_reg_put_constraints(cpuc, xreg);
> > -                       c = d;
> > -               }
> > -       }
> >         return c;
> >  }
> >
> > @@ -1629,17 +1618,18 @@ x86_get_event_constraints(struct
> cpu_hw_events
> > *cpuc, struct perf_event *event)  static struct event_constraint *
> > intel_get_event_constraints(struct cpu_hw_events *cpuc, struct
> > perf_event *event)  {
> > -       struct event_constraint *c;
> > +       struct event_constraint *c, *d;
> >
> >         c = intel_bts_constraints(event);
> >         if (c)
> >                 return c;
> >
> > -       c = intel_pebs_constraints(event);
> > -       if (c)
> > -               return c;
> > +       c = intel_shared_regs_constraints(cpuc, event, &event-
> >hw.branch_reg);
> > +       d = intel_pebs_constraints(event);
> > +       if (d || c)
> > +               return (d) ? (d) : (c);
> >
> > -       c = intel_shared_regs_constraints(cpuc, event);
> > +       c = intel_shared_regs_constraints(cpuc, event,
> > + &event->hw.extra_reg);
> >         if (c)
> >                 return c;
> >
> 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;
>    ...
> }
> 
> 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 didn’t change __intel_shared_reg_get_constraints and its input. 
So using LBR on the L1D_PEND_MISS event, it would return NULL.
		/*
		 * need to call x86_get_event_constraint()
		 * to check if associated event has constraints
		 */
		c = NULL;
Since it's not PEBS, intel_pebs_constraints will also return NULL.
So it will not return. It will continue to check extra_reg and finally
check if associated event has constraints.
>I
> think in the presence of LBR, you always need to call share_get_reg() and
> x86_get_event_constraint().
> This is to ensure that both the shared constraint AND the event constraint
> are satisfied (and of course, in case one fails, the other needs to be
> released).
> 
The patch doesn't change the behavior for non-PEBS event.

Thanks,
Kan
> 
> > --
> > 1.8.3.2
> >
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

  reply	other threads:[~2015-03-26 20:21 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 [this message]
2015-03-26 21:02     ` Stephane Eranian
2015-03-27 12:10   ` Peter Zijlstra
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=37D7C6CF3E00A74B8858931C1DB2F07701778F3E@SHSMSX103.ccr.corp.intel.com \
    --to=kan.liang@intel.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=andi@firstfloor.org \
    --cc=eranian@google.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.