From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753420AbcCSJ0i (ORCPT ); Sat, 19 Mar 2016 05:26:38 -0400 Received: from www.linutronix.de ([62.245.132.108]:39357 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752283AbcCSJ03 (ORCPT ); Sat, 19 Mar 2016 05:26:29 -0400 Date: Sat, 19 Mar 2016 10:24:59 +0100 (CET) From: Thomas Gleixner To: Peter Zijlstra cc: LKML , Ingo Molnar , bp@alien8.de, aherrmann@suse.com, jencce.kernel@gmail.com, Rui Huang Subject: Re: [PATCH 2/3] x86/topology: Fix AMD core count In-Reply-To: <20160318150538.551407299@infradead.org> Message-ID: References: <20160318150345.146716865@infradead.org> <20160318150538.551407299@infradead.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001,URIBL_BLOCKED=0.001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 18 Mar 2016, Peter Zijlstra wrote: > It turns out AMD gets x86_max_cores wrong when there are compute > units. > > The issue is that Linux assumes: > > nr_logical_cpus = nr_cores * nr_siblings > > But AMD reports its CU unit as 2 cores, but then sets num_smp_siblings > to 2 as well. > > Cc: Ingo Molnar > Cc: Borislav Petkov > Cc: Thomas Gleixner > Cc: Andreas Herrmann > Reported-by: Xiong Zhou > Fixes: 1f12e32f4cd5 ("x86/topology: Create logical package id") > Signed-off-by: Peter Zijlstra (Intel) > Link: http://lkml.kernel.org/r/20160317095220.GO6344@twins.programming.kicks-ass.net > --- > arch/x86/kernel/cpu/amd.c | 8 ++++---- > arch/x86/kernel/smpboot.c | 11 ++++++----- > 2 files changed, 10 insertions(+), 9 deletions(-) > > --- a/arch/x86/kernel/cpu/amd.c > +++ b/arch/x86/kernel/cpu/amd.c > @@ -313,9 +313,9 @@ static void amd_get_topology(struct cpui > node_id = ecx & 7; > > /* get compute unit information */ > - smp_num_siblings = ((ebx >> 8) & 3) + 1; > + cores_per_cu = smp_num_siblings = ((ebx >> 8) & 3) + 1; > + c->x86_max_cores /= smp_num_siblings; Unfortunately that will break stuff in event/amd/core.c, ras/mce_amd_inj.c which rely on the AMD interpretation of c->x86_max_cores. I'm seriously grumpy about pointless inconsistent representations depending on the CPU vendor. That's just lazy and sloppy hackery from the "works for me" departement. For now we'll get away with Peters workaround for the Intel HT mess, which is a different kind of mental insanity invented by HW/BIOS people, but this topology stuff needs to be made consistent ASAP. Thanks, tglx