public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: "Liang, Kan" <kan.liang@intel.com>
Cc: "mingo@kernel.org" <mingo@kernel.org>,
	"acme@infradead.org" <acme@infradead.org>,
	"eranian@google.com" <eranian@google.com>,
	"andi@firstfloor.org" <andi@firstfloor.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V7 3/6] perf, x86: handle multiple records in PEBS buffer
Date: Tue, 5 May 2015 19:08:22 +0200	[thread overview]
Message-ID: <20150505170822.GQ23123@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <37D7C6CF3E00A74B8858931C1DB2F0770180BB27@SHSMSX103.ccr.corp.intel.com>

On Tue, May 05, 2015 at 04:30:25PM +0000, Liang, Kan wrote:
> > > +	for (at = base; at < top; at += x86_pmu.pebs_record_size) {
> > >  		struct pebs_record_nhm *p = at;
> > >
> > >  		for_each_set_bit(bit, (unsigned long *)&p->status,
> > >  				 x86_pmu.max_pebs_events) {
> > >  			event = cpuc->events[bit];
> > >  			WARN_ON_ONCE(!event);
> > >
> > > +			if (event->attr.precise_ip)
> > > +				break;
> > > +		}
> > 
> > Would it make sense to delay looking for the event until you've found
> > there is a single bit set -- and already know which bit that is?
> >
> 
> Yes, I think we can test cpuc->pebs_enabled here.
> It should be better than attr.precise_ip checking.
> 
> -       for (; at < top; at += x86_pmu.pebs_record_size) {
> +       for (at = base; at < top; at += x86_pmu.pebs_record_size) {
>                 struct pebs_record_nhm *p = at;
> 
>                 for_each_set_bit(bit, (unsigned long *)&p->status,
>                                  x86_pmu.max_pebs_events) {
> -                       event = cpuc->events[bit];
> -                       if (!test_bit(bit, cpuc->active_mask))
> -                               continue;
> -
> -                       WARN_ON_ONCE(!event);
> 
> -                       if (!event->attr.precise_ip)
> -                               continue;
> +                       if (test_bit(bit, cpuc->pebs_enabled))
> +                               break;
> +               }
> 

Can't we take that entire for_each_set_bit() loop out?

It appears to me we effectively do that single test_bit() test you left
in there already with the & cpuc->pebs_enabled later on.


>  
> +       for (bit = 0; bit < x86_pmu.max_pebs_events; bit++) {
> +               if (counts[bit] == 0)
>                         continue;
> -
> -               __intel_pmu_pebs_event(event, iregs, at);
> +               event = cpuc->events[bit];
> +               WARN_ON_ONCE(!event);
> +               WARN_ON_ONCE(!event->attr.precise_ip);
> +               __intel_pmu_pebs_event(event, iregs, base,
> +                                      top, bit, counts[bit]);
>         }

Right bit of paranoia :-)



  reply	other threads:[~2015-05-05 17:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-20  8:07 [PATCH V7 0/6] large PEBS interrupt threshold Kan Liang
2015-04-20  8:07 ` [PATCH V7 1/6] perf, x86: use the PEBS auto reload mechanism when possible Kan Liang
2015-04-20  8:07 ` [PATCH V7 2/6] perf, x86: introduce setup_pebs_sample_data() Kan Liang
2015-04-20  8:07 ` [PATCH V7 3/6] perf, x86: handle multiple records in PEBS buffer Kan Liang
2015-05-05 13:07   ` Peter Zijlstra
2015-05-05 13:17     ` Peter Zijlstra
2015-05-05 16:36       ` Liang, Kan
2015-05-05 17:00         ` Peter Zijlstra
2015-05-05 13:16   ` Peter Zijlstra
2015-05-05 16:30     ` Liang, Kan
2015-05-05 17:08       ` Peter Zijlstra [this message]
2015-05-05 17:22         ` Liang, Kan
2015-05-06 13:01       ` Andi Kleen
2015-05-06 13:13         ` Peter Zijlstra
2015-04-20  8:07 ` [PATCH V7 4/6] perf, x86: large PEBS interrupt threshold Kan Liang
2015-04-20  8:07 ` [PATCH V7 5/6] perf, x86: drain PEBS buffer during context switch Kan Liang
2015-04-20  8:07 ` [PATCH V7 6/6] perf, x86: enlarge PEBS buffer Kan Liang

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=20150505170822.GQ23123@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@infradead.org \
    --cc=andi@firstfloor.org \
    --cc=eranian@google.com \
    --cc=kan.liang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox