[Intel-gfx] [RFC v2 2/3] drm/i915/pmu: serve global events and support perf stat

Peter Zijlstra peterz at infradead.org
Tue Aug 29 09:28:33 UTC 2017


On Wed, Aug 23, 2017 at 11:38:43PM +0000, Rogozhkin, Dmitry V wrote:
> On Wed, 2017-08-23 at 08:26 -0700, Dmitry Rogozhkin wrote:
> > +static cpumask_t i915_pmu_cpumask = CPU_MASK_CPU0;
> 
> Peter, this hardcoding of cpumask to use CPU0 works, but should I
> implement something smarter or this will be sufficient? I see that
> cstate.c you have pointed me to tries to track CPUs going online/offline
> and migrates PMU context to another CPU if selected one went offline.
> Should I follow this way?

Yes.. x86 used to not allow hotplug of CPU0, but they 'fixed' that :/

And the perf core needs _a_ valid CPU to run things from, which leaves
you having to track online/offline things.

Now, I suppose its all fairly similar for a lot of uncore PMUs, so maybe
you can pull some of this into a library and avoid the endless
duplication between all (most?) uncore driveres.

> If I should track CPUs going online/offline, then I have questions:
> 1. How I should register tracking callbacks? I see that cstate.c
> registers CPUHP_AP_PERF_X86_CSTATE_STARTING and
> CPUHP_AP_PERF_X86_CSTATE_ONLINE, uncore.c registers
> CPUHP_AP_PERF_X86_UNCORE_ONLINE. What I should use? I incline to UNCORE.

Egads, what a mess :/ Clearly I didn't pay too much attention there.

So ideally we'd not hate a state per PMU, and
__cpuhp_setup_state_cpuslocked() has a .multi_instance argument that
allows reuse of a state.

So yes, please use the PERF_X86_UNCORE ones if possible.

> 2. If I will register for, say UNCORE, then how double registrations
> will be handled if both uncore.c and i915.c will register callbacks? Any
> conflict here?

Should work with .multi_instance I _think_, I've not had the pleasure of
using the new and improved CPU hotplug infrastructure much.

> 3. What I should pass as 2nd argument? Will "perf/x86/intel/i915:online"
> be ok?

Yeah, whatever I think.. something unique. Someone or something will
eventually yell if its no good I suppose ;-)


More information about the Intel-gfx mailing list