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(-)
diff --git a/arch/x86/kernel/cpu/perf_event_amd.c b/arch/x86/kernel/cpu/perf_event_amd.c
index 95e7fe1..9edc786 100644
--- a/arch/x86/kernel/cpu/perf_event_amd.c
+++ b/arch/x86/kernel/cpu/perf_event_amd.c
@@ -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;
}
On Wed, May 23, 2012 at 2:50 PM, Ingo Molnar <[email protected]> wrote:
> 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.
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
On Wed, May 23, 2012 at 2:56 PM, Josh Boyer <[email protected]> wrote:
> On Wed, May 23, 2012 at 2:50 PM, Ingo Molnar <[email protected]> wrote:
>> 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.
>
> 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
Possibly this one too:
http://git.kernel.org/?p=linux/kernel/git/tip/tip.git;a=commitdiff;h=e326e7524531c5c6de4a8cf8eeed60b4a9f47637
josh
* Josh Boyer <[email protected]> wrote:
> On Wed, May 23, 2012 at 2:50 PM, Ingo Molnar <[email protected]> wrote:
> > 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.
>
> Perf doesn't even build in Linus' current tree.
Yes, that's a regression in some build environments. (it builds
fine in our environments, that's why it wasn't noticed.)
> [...] You might want to include
>
> http://git.kernel.org/?p=linux/kernel/git/tip/tip.git;a=commitdiff;h=8784eb7497b928de33a715e26da2bd51d424bec1
>
> with your pull request.
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
On Wed, May 23, 2012 at 4:04 PM, Ingo Molnar <[email protected]> wrote:
>
> * Josh Boyer <[email protected]> wrote:
>> Perf doesn't even build in Linus' current tree.
>
> Yes, that's a regression in some build environments. (it builds
> fine in our environments, that's why it wasn't noticed.)
>
>> [...] ?You might want to include
>>
>> http://git.kernel.org/?p=linux/kernel/git/tip/tip.git;a=commitdiff;h=8784eb7497b928de33a715e26da2bd51d424bec1
>>
>> with your pull request.
>
> I sent that (and other fixes) to Linus too, earlier today.
I saw that. Thank you.
> This pull request you replied to is the v3.4 era fixes tree,
> with one remaining fix in it.
I see. The forest of tip trees apparently confuses me still. I'll
figure it out eventually.
josh
* Josh Boyer <[email protected]> wrote:
> > This pull request you replied to is the v3.4 era fixes tree,
> > with one remaining fix in it.
>
> I see. The forest of tip trees apparently confuses me still.
> I'll figure it out eventually.
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