Re: HW perf initialisation as early_initcall

[Peter Zijlstra]

On Wed, 2011-11-23 at 14:56 +0000, Will Deacon wrote:
> Hi Peter,
> 
> In commit 004417a6 ("perf, arch: Cleanup perf-pmu init vs lockup-detector"),
> you moved the arch hw perf initialisation into an early initcall to satisfy a
> race with the NMI lock detector (I'm not clear on what the relationship is).

NMI watchdog uses perf, getting the NMI watchdog up early is good,
getting it up before perf is initialized, not so very good :-)

> Anyway, with ARM big/little platforms on the horizon we have the fun of
> heterogeneous PMUs in the sense that:
> 
> 	- They may have different numbers of event counters
> 	- They may support different event types (possibly a distinct set)
> 	- The event encodings for the generalised events may be different
> 
> The latter two points I think can be solved in the back-end by making events
> affine to a particular PMU type (that is, they are only scheduled when the
> profiled task is running on a given PMU type), although I'm not sure how this
> will be exposed to userspace yet. It might be nice to register a separate
> PMU with perf altogether, but I don't think the userspace tools are there
> yet in terms of specifying the destination PMU for an event.

Ow gawd, that's horrid, will you please kick your cpu folks for me.

> The first point is part of a bigger problem, namely that we can only find
> out the PMU topology of the system by probing the device tree. For older
> platforms, we will still probe the PMU of the boot CPU by inspecting the ID
> registers.

And here I throught DT was up _waaay_ early because its used to bring up
the platform itself, do I need to re-educate myself?

> My question is: does the hw perf initialisation really need to be an
> early_initcall and, if so, how much of the perf backend needs to be up and
> running? It may be that the early initcall assumes all PMUs are the same and
> then later on I go and rewrite things like the number of counters.

I think you can get away with doing it later, since you don't use the
NMI watchdog (although if you ever get NMI like functionality you really
should).

> Of course, any ideas regarding the above are more than welcome!

Yeah, I'll try and let it soak in my brain, who knows what it'll come up
with ;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/