From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751939AbcKGHb0 (ORCPT ); Mon, 7 Nov 2016 02:31:26 -0500 Received: from mail-wm0-f67.google.com ([74.125.82.67]:32771 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750953AbcKGHbZ (ORCPT ); Mon, 7 Nov 2016 02:31:25 -0500 Date: Mon, 7 Nov 2016 08:31:21 +0100 From: Ingo Molnar To: Borislav Petkov Cc: x86@kernel.org, Yazen Ghannam , linux-kernel@vger.kernel.org, Peter Zijlstra Subject: Re: [PATCH v3 1/2] x86/AMD: Fix cpu_llc_id for AMD Fam17h systems Message-ID: <20161107073121.GB26938@gmail.com> References: <1478019063-2632-1-git-send-email-Yazen.Ghannam@amd.com> <20161102201321.slgzk2x2ya4jzfax@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161102201321.slgzk2x2ya4jzfax@pd.tnic> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Borislav Petkov wrote: > Lemme clean up the commit message a bit more and add tags: > > --- > From: Yazen Ghannam > Date: Tue, 1 Nov 2016 11:51:02 -0500 > Subject: [PATCH] x86/AMD: Fix cpu_llc_id for AMD Fam17h systems > > cpu_llc_id (Last Level Cache ID) derivation on AMD Fam17h has an > underflow bug when extracting the socket_id value. It starts from 0 > so subtracting 1 from it will result in an invalid value. This breaks > scheduling topology later on since the cpu_llc_id will be incorrect. > > The APIC ID is preset in APICx020 for bits 3 and above: they contain the > core complex, node and socket IDs. > > The LLC is at the core complex level so we can find a unique cpu_llc_id > by right shifting the APICID by 3 because then the least significant bit > will be the Core Complex ID. Same question as for the previous patch: what are the effects of the bug: - Outright bad scheduling? - Suboptimal scheduling? - Crash? - Something else? Such information needs to be in commit messages, _especially_ when a Cc: stable tag is added as well. Thanks, Ingo