Messages in this thread | | | Date | Tue, 29 May 2012 20:58:43 +0200 | From | Andreas Herrmann <> | Subject | Re: [rfc][patch] select_idle_sibling() inducing bouncing on westmere |
| |
On Sat, May 26, 2012 at 09:29:24AM +0200, Peter Zijlstra wrote: > On Sat, 2012-05-26 at 08:37 +0200, Mike Galbraith wrote: > > > Ew. 3.4 went broke for Q6600, and performance went... far far away. > > > > [ 0.200057] CPU0 attaching sched-domain: > > [ 0.204016] domain 0: span 0-3 level MC > > [ 0.208015] groups: 0 1 2 3 > > [ 0.210970] CPU1 attaching sched-domain: > > [ 0.212014] domain 0: span 0-3 level MC > > [ 0.216016] groups: 1 2 3 0 > > [ 0.220016] CPU2 attaching sched-domain: > > [ 0.224015] domain 0: span 0-3 level MC > > [ 0.228016] groups: 2 3 0 1 > > [ 0.232015] CPU3 attaching sched-domain: > > [ 0.236016] domain 0: span 0-3 level MC > > [ 0.240017] groups: 3 0 1 2 > > > Oh yikes, I guess I wrecked > arch/x86/kernel/smpboot.c:cpu_coregroup_mask() in > 8e7fbcbc22c12414bcc9dfdd683637f58fb32759. > > That should very much always return llc mask, I just got that AMD case > confused. It looks like it should look like: > > > const struct cpumask *cpu_coregroup_mask(int cpu) > { > return cpu_llc_mask(cpu); > } > > And the AMD_DCM check was just to undo powersavings damage on > Magny-Cours or somesuch.
IIRC returning cpu_core_mask() could even cause a panic in the scheduler, because the hierarchy of scheduling groups/domains was broken.
> Andreas?
Returning cpu_llc_mask is the right thing to do on AMD.
Andreas
| |