linux-kernel - HW perf initialisation as early

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 23 Nov 2011 14:56:58 +0000
From:	Will Deacon <will.deacon@....com>
To:	a.p.zijlstra@...llo.nl
Cc:	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: HW perf initialisation as early_initcall

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).

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.

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.

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.

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

Cheers,

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/