From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755249AbcCTKjx (ORCPT ); Sun, 20 Mar 2016 06:39:53 -0400 Received: from casper.infradead.org ([85.118.1.10]:34949 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754117AbcCTKjw (ORCPT ); Sun, 20 Mar 2016 06:39:52 -0400 Date: Sun, 20 Mar 2016 11:39:46 +0100 From: Peter Zijlstra To: Thomas Gleixner 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 Message-ID: <20160320103946.GL6344@twins.programming.kicks-ass.net> References: <20160318150345.146716865@infradead.org> <20160318150538.551407299@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Mar 19, 2016 at 10:24:59AM +0100, Thomas Gleixner wrote: > 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. So the AMD NB stuff in events/amd/core.c is only for Fam10, Fam15 got its own uncore driver. (Fam10 had the uncore events through the same counters as the core PMU with with 'fun' constraints). And since Fam10 isn't affected by this change in x86_max_cores, this _should_ work out, IF that NB code knows to switch off properly when not required.