Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756426AbcK2VCc (ORCPT ); Tue, 29 Nov 2016 16:02:32 -0500 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]:2101 "EHLO mail3-relais-sop.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754549AbcK2VCX (ORCPT ); Tue, 29 Nov 2016 16:02:23 -0500 X-IronPort-AV: E=Sophos;i="5.31,570,1473112800"; d="scan'208";a="202216750" Subject: Re: AMD Bulldozer topology regression since 4.6 To: Borislav Petkov References: <583D2833.4030508@inria.fr> <20161129193923.x2i6hctkdwalzfn5@pd.tnic> From: Brice Goglin Cc: LKML , Thomas Gleixner Message-ID: <583DECC8.4000507@inria.fr> Date: Tue, 29 Nov 2016 22:02:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.8.0 MIME-Version: 1.0 In-Reply-To: <20161129193923.x2i6hctkdwalzfn5@pd.tnic> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2631 Lines: 79 Le 29/11/2016 20:39, Borislav Petkov a écrit : > Does that fix it? > > Patch is against latest tip/master because we have some more changes in > that area. I tested the second patch on top of 4.8.11, it brings core_id back to where it was before 4.6, thanks. Reported-and-tested-by: Brice Goglin However thread_siblings isn't back to where it was in 4.5. Now we have a single bit in each thread_siblings mask. That's correct with respect to the sysfs topology documentation. In 4.5, there were two bits (one for each core of the compute unit), which was wrong (cores with different core_ids shouldn't appear in each other thread_siblings). I assumed that these processors had to break the sysfs topology documentation to expose the concept of "dual-core compute-unit" which somehow sits between hyperthreading and dual-core. I personally do not care much about this regression, not sure about other user-space tools? Another minor related change: /proc/cpuinfo shows "cpu cores : 16" instead of "8". Brice > > --- > diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c > index 4daad1e39352..a070d7b0a133 100644 > --- a/arch/x86/kernel/cpu/amd.c > +++ b/arch/x86/kernel/cpu/amd.c > @@ -305,15 +305,7 @@ static void amd_get_topology(struct cpuinfo_x86 *c) > > /* get information required for multi-node processors */ > if (boot_cpu_has(X86_FEATURE_TOPOEXT)) { > - u32 eax, ebx, ecx, edx; > - > - cpuid(0x8000001e, &eax, &ebx, &ecx, &edx); > - node_id = ecx & 7; > - > - /* get compute unit information */ > - smp_num_siblings = ((ebx >> 8) & 3) + 1; > - c->x86_max_cores /= smp_num_siblings; > - c->cpu_core_id = ebx & 0xff; > + node_id = cpuid_ecx(0x8000001e) & 7; > > /* > * We may have multiple LLCs if L3 caches exist, so check if we > --- > > Just in case, I have one against Linus' master too: > > --- > diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c > index 1e81a37c034e..19f50a9d6b42 100644 > --- a/arch/x86/kernel/cpu/amd.c > +++ b/arch/x86/kernel/cpu/amd.c > @@ -305,15 +305,7 @@ static void amd_get_topology(struct cpuinfo_x86 *c) > > /* get information required for multi-node processors */ > if (boot_cpu_has(X86_FEATURE_TOPOEXT)) { > - u32 eax, ebx, ecx, edx; > - > - cpuid(0x8000001e, &eax, &ebx, &ecx, &edx); > - node_id = ecx & 7; > - > - /* get compute unit information */ > - smp_num_siblings = ((ebx >> 8) & 3) + 1; > - c->x86_max_cores /= smp_num_siblings; > - c->cpu_core_id = ebx & 0xff; > + node_id = cpuid_ecx(0x8000001e) & 7; > } else if (cpu_has(c, X86_FEATURE_NODEID_MSR)) { > u64 value; > --- >