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

[Rogozhkin, Dmitry V]

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.
> 
> Now, I'm thinking that what i915 does is slightly different, it doesn't
> provide registers to read out the counter state, but instead
> periodically writes state snapshots into some memory buffer, right?
> 
> That's a bit tricky, maybe the best fit would be what PPC HV 24x7 does.
> They create an event-group, that is a set of counters that are
> co-scheduled, matching the set of counters they get from the HV
> interface (or a subset) and then sys_read() will use a TXN_READ to
> group-read the entire thing at once. In your case it could consume the
> last state snapshot instead of request one (or wait for the next,
> whatever works best).
> 
> Would that work?

Hi Peter,

I have updated my fixes to Tvrtko's PMU, they are here:
https://patchwork.freedesktop.org/series/28842/, and I started to check
whether we will be able to cover all the use cases for this PMU which we
had in mind. Here I have some concerns and further questions.

So, as soon as I registered PMU with the perf_invalid_context, i.e. as
an uncore PMU, I got the effect that metrics from our PMU are available
under root only. This happens since we fall to the following case
described in 'man perf_event_open': "A pid == -1 and cpu >= 0 setting is
per-CPU and measures all processes on the specified CPU.  Per-CPU events
need  the  CAP_SYS_ADMIN  capability  or
a /proc/sys/kernel/perf_event_paranoid value of less than 1."

This a trouble point for us... So, could you, please, clarify:
1. How PMU API is positioned? It is for debug purposes only or it can be
used in the end-user release applications to monitor system activity and
make some decisions based on that?
2. How applications can access uncore PMU metrics from non-privileged
applications?
3. Is that a strong requirement to restrict uncore PMU metrics reporting
to privileged applications or this can be relaxed?


I understand why restriction was relevant in the time when only CPU
level were available: system-wide were expensive, but I don't quite
understand why these restrictions are in place now for uncore PMUs when
they actually report metrics right away. Is that just a remnant of
CPU-only times and no one needed this to be changed? Can this be changed
and uncore metrics allowed to be accessed from general applications?


Regards,
Dmitry.