perf fix

Linus,

Please pull the latest perf-urgent-for-linus git tree from:

git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf-urgent-for-linus

HEAD: 5bcdf5e4fee3c45e1281c25e4941f2163cb28c65 perf/x86: Update event scheduling constraints for AMD family 15h models

Leftover AMD PMU driver fix fix from the end of the v3.4 stabilization cycle.

Thanks,

Ingo

------------------>
Robert Richter (1):
perf/x86: Update event scheduling constraints for AMD family 15h models

 arch/x86/kernel/cpu/perf_event_amd.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

index 95e7fe1..9edc786 100644
@@ -493,6 +493,7 @@ static __initconst const struct x86_pmu amd_pmu = {
  * 0x023	DE	PERF_CTL[2:0]
  * 0x02D	LS	PERF_CTL[3]
  * 0x02E	LS	PERF_CTL[3,0]
+ * 0x031	LS	PERF_CTL[2:0] (**)
  * 0x043	CU	PERF_CTL[2:0]
  * 0x045	CU	PERF_CTL[2:0]
  * 0x046	CU	PERF_CTL[2:0]

@@ -506,10 +507,12 @@ static __initconst const struct x86_pmu amd_pmu = {
  * 0x0DD	LS	PERF_CTL[5:0]
  * 0x0DE	LS	PERF_CTL[5:0]
  * 0x0DF	LS	PERF_CTL[5:0]
+ * 0x1C0	EX	PERF_CTL[5:3]
  * 0x1D6	EX	PERF_CTL[5:0]
  * 0x1D8	EX	PERF_CTL[5:0]
  *
- * (*) depending on the umask all FPU counters may be used
+ * (*)  depending on the umask all FPU counters may be used
+ * (**) only one unitmask enabled at a time
  */
 
 static struct event_constraint amd_f15_PMC0  = EVENT_CONSTRAINT(0, 0x01, 0);

@@ -559,6 +562,12 @@ amd_get_event_constraints_f15h(struct cpu_hw_events *cpuc, struct perf_event *ev
 			return &amd_f15_PMC3;
 		case 0x02E:
 			return &amd_f15_PMC30;
+		case 0x031:
+			if (hweight_long(hwc->config & ARCH_PERFMON_EVENTSEL_UMASK) <= 1)
+				return &amd_f15_PMC20;
+			return &emptyconstraint;
+		case 0x1C0:
+			return &amd_f15_PMC53;
 		default:
 			return &amd_f15_PMC50;
 		}

Perf doesn't even build in Linus' current tree. You might want to include

http://git.kernel.org/?p=linux/kernel/git/tip/tip.git;a=commitdiff;h=8784eb7497b928de33a715e26da2bd51d424bec1

with your pull request.

josh

Possibly this one too:

http://git.kernel.org/?p=linux/kernel/git/tip/tip.git;a=commitdiff;h=e326e7524531c5c6de4a8cf8eeed60b4a9f47637

josh

Yes, that's a regression in some build environments. (it builds fine in our environments, that's why it wasn't noticed.)

I sent that (and other fixes) to Linus too, earlier today.

This pull request you replied to is the v3.4 era fixes tree, with one remaining fix in it.

Thanks,

Ingo

I saw that. Thank you.

I see. The forest of tip trees apparently confuses me still. I'll figure it out eventually.

josh

The topic tree layout for single-topic trees is pretty simple and straightforward - but the situation you met here was arguably a weird corner case:

X/urgent are the fixes that go to Linus
X/core are the development patches for the next merge window

Where 'X' can be one of: perf, sched, timer, irq - the main subsystem trees we maintain. (x86 is a multi-topic tree, with intuitively named topic trees, such as x86/reboot, x86/asm or x86/mm.)

All of them are test-merged into tip:master - this is the one that you will typically use, the topic layout is for maintainers and for power-contributors/submaintaners who are sending Git pull requests to us.

at the beginning of a merge window (i.e. right now) there might be fixes pending in perf/urgent that did not make it to v3.4. Instead of merging them into perf/core I tend to send them to Linus as a standalone tree.

The rest of perf/core, once the initial one or two sets of commits get pulled by Linus, morphs into perf/urgent, fairly early in the merge window.

Thus there's a new perf/urgent and an empty perf/core, and the cycle starts again.

You met this cycle switch period to the day (the chance is only 1:90 for that, consider yourself lucky ;-), which created the impression of a confusing fixes workflow.

Thanks,

Ingo