lkml.org 
[lkml]   [2012]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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




\
 
 \ /
  Last update: 2012-05-29 21:21    [W:1.982 / U:0.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site