All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Len Brown <len.brown@intel.com>,
	Paul Mackerras <paulus@samba.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Ingo Molnar <mingo@redhat.com>
Subject: Re: [RFC] x86, perf: Add an aperfmperf driver
Date: Thu, 30 Apr 2015 10:51:22 +0200	[thread overview]
Message-ID: <20150430085122.GV5029@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <CALCETrXej48QEjOLtxH52DHGOjG9mW0KaydEYhrB6=NP3WmzGg@mail.gmail.com>

On Wed, Apr 29, 2015 at 06:17:05PM -0700, Andy Lutomirski wrote:
> >> > +     /* no sampling */
> >> > +     if (event->hw.sample_period)
> >> > +             return -EINVAL;
> >>
> >> You could have set pmu::capabilities =
> >> PERF_PMU_CAP_NO_INTERRUPT which would also have killed that dead.
> >
> >
> > That checks attr.sample_period.  I'm a bit confused about the
> > relationship between event->hw and event->attr.  Do I not need to
> > check hw.sample_period?

event->attr is the perf_event_attr used to instantiate the event.
event->hw is the hardware/working state of the event.

You'll notice that attr::sample_period is part of a union and when
!attr::freq will be used as the actual hw::sample_period. However when
attr::freq we'll compute hw::sample_period based on actual event rates
such that we'll approx attr::sample_freq.

Setting pmu::capabilities = PERF_PMU_CAP_NO_INTERRUPT would be the best
solution here.

> > Before I submit v2, do you think this is actually worth doing?  I can
> > see it being useful for answering questions like "did this workload
> > end up running at full speed".
> >
> 
> To clarify, this is partially redundant with "cpu-cycles" and
> "ref-cycles".  That being said, these are simpler, actually documented
> as being appropriate for measuring cpu performance states, and don't
> have any scheduling constraints.

On the whole useful question; I dunno. It seems like something worth
providing for the reasons you state. But I don't really get around to
doing much userspace these days so I might not be the best to answer
this.

Also, you could extend this with IA32_PPERF (Skylake and later, see
SDM-201501 book 3 section 14.4.5.1).

> Also, is perf stat able to count while idle?  perf stat -a -e
> cpu-cycles sleep 1 reports very small numbers.

Yes, perf stat -a (iow cpu events) should count while idle, note however
that not all events count during halt, so its very much event dependent.

  reply	other threads:[~2015-04-30  8:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-28 21:25 [RFC] x86, perf: Add an aperfmperf driver Andy Lutomirski
2015-04-28 22:29 ` Brown, Len
2015-04-28 22:43   ` Andy Lutomirski
2015-04-29  9:13     ` Peter Zijlstra
2015-04-29  9:09 ` Peter Zijlstra
2015-04-29 18:50   ` Andy Lutomirski
2015-04-30  1:17     ` Andy Lutomirski
2015-04-30  8:51       ` Peter Zijlstra [this message]
2015-04-30 22:09         ` Andy Lutomirski
2015-04-29  9:14 ` Peter Zijlstra
2015-05-11  9:48 ` Ingo Molnar

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=20150430085122.GV5029@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@kernel.org \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=paulus@samba.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.