[Intel-gfx] [RFC 04/10] drm/i915: Expose a PMU interface for perf queries

[Peter Zijlstra]

On Wed, Aug 23, 2017 at 07:00:33PM +0000, Rogozhkin, Dmitry V wrote:
> On Wed, 2017-08-23 at 20:22 +0200, Peter Zijlstra wrote:
> > On Wed, Aug 23, 2017 at 05:51:38PM +0000, Rogozhkin, Dmitry V wrote:
> > 
> > > Anyhow, returning to the metrics i915 exposes. Some metrics are just
> > > exposure of some counters supported already inside i915 PMU which do not
> > > require any special sampling: at any given moment you can request the
> > > counter value (these are interrupts counts, i915 power consumption).
> > 
> > > Other metrics are similar to the ever-existing which I just described,
> > > but they require activation for i915 to start to count them - this is
> > > done on the event initialization (these are engine busy stats).
> > 
> > Right, so depending on how expensive this activation is and if it can be
> > done without scheduling, there are two options:
> > 
> >  1) activate/deactivate from pmu::start()/pmu::stop()
> >  2) activate/deactivate from pmu::event_init()/event->destroy() and
> >     disregard all counting between pmu::stop() and pmu::start().
> > 
> > > Finally, there is a third group which require sampling counting: they
> > > are needed to be initialized and i915 pmu starts an internal timer to
> > > count these values (these are some engines characteristics referenced
> > > in the code as QUEUED, SEMA, WAIT).
> > 
> > So uncore PMUs can't really do sampling. That is, perf defines sampling
> > as interrupting the relevant task and then providing things like the
> > %RIP value at interrupt time. Since uncore activity cannot be associated
> > with any one task, no sampling allowed.
> 
> I read this as we need to add:
> static int i915_pmu_event_init(struct perf_event *event)
> {
> ...
> 	/* Sampling not supported yet */
> 	if (hwc->sample_period)
> 		return -EINVAL;
> ...
> }
> And deny sampling period for our events, right? 

Something like that, yes.


> And what should happen
> is that the following command will start to fail: "perf stat -e ev -a -I
> 100"? 

No, perf stat -I works by userspace doing sys_read() with a userspace
timer.

It will stop perf-record from working.