Re: [RFC PATCH 00/11] drm/i915: Expose OA metrics via perf PMU

From: Ingo Molnar <mingo@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Robert Bragg <robert@sixbynine.org>,
	intel-gfx@lists.freedesktop.org,
	Daniel Vetter <daniel.vetter@intel.com>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	David Airlie <airlied@linux.ie>,
	Paul Mackerras <paulus@samba.org>, Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-api@vger.kernel.org
Subject: Re: [RFC PATCH 00/11] drm/i915: Expose OA metrics via perf PMU
Date: Wed, 27 May 2015 18:41:17 +0200	[thread overview]
Message-ID: <20150527164116.GA27857@gmail.com> (raw)
In-Reply-To: <20150527153914.GC3644@twins.programming.kicks-ass.net>

* Peter Zijlstra <peterz@infradead.org> wrote:

> > As it is currently the kernel doesn't need to know anything about the 
> > semantics of individual counters being selected, so it's currently convenient 
> > that we can aim to maintain all the counter meta data we have in userspace 
> > according to the changing needs of tools or drivers (e.g. names, descriptions, 
> > units, max values, normalization equations), de-coupled from the kernel, 
> > instead of splitting it between the kernel and userspace.
> 
> And that fully violates the design premise of perf. The kernel should be in 
> control of resources, not userspace.
> 
> If we'd have put userspace in charge, we could now not profile the same task by 
> two (or more) different observers. But with kernel side counter management that 
> is no problem at all.

Beyond that there are a couple of other advantages of managing performance metrics 
via the kernel:

2)

Per task/workload/user separation of events, for example you can do:

	perf record make bzImage
        perf stat make bzImage

These will only profile/count in the child task hierarchy spawned by the shell. 
Multiple such sessions can be started and the perf sampling/counting of the 
separate workloads is independent of each other.

3)

Finegrained security model: you can chose which events to expose to what privilege 
levels. You can also work around hardware bugs without complicating tooling.

4)

Seemless integration of the various PMU and other event metrics with each other: 
you can start a CPU PMU event, a trace event, a software event and an uncore 
event, which all output into the same coherent, ordered ring-buffer, timestamped 
and correlated consistently, etc.

5)

The unified event model on the kernel side also brings with itself 100 KLOC of 
rich, unified tooling in tools/perf/, which tries to keep it all together and 
functional.

================

The cost of all that is having to implement kernel support for it, but once that 
initial hurdle is taken, it's well worth it! A PMU driver can be as simple as 
offering only a single system-wide counter.

Thanks,

	Ingo