From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932287AbcKGOH6 (ORCPT ); Mon, 7 Nov 2016 09:07:58 -0500 Received: from mail-wm0-f68.google.com ([74.125.82.68]:33291 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932194AbcKGOH4 (ORCPT ); Mon, 7 Nov 2016 09:07:56 -0500 Date: Mon, 7 Nov 2016 15:07:46 +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: <20161107140746.GA20626@gmail.com> References: <1478019063-2632-1-git-send-email-Yazen.Ghannam@amd.com> <20161102201321.slgzk2x2ya4jzfax@pd.tnic> <20161107073121.GB26938@gmail.com> <20161107092031.alxfkr6rpctodbdk@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161107092031.alxfkr6rpctodbdk@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: > On Mon, Nov 07, 2016 at 08:31:21AM +0100, Ingo Molnar wrote: > > > 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 > > How's this... > > > > 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. > ^^^^^^^^^^^^^^^^^^^ > ... here? > > > Same question as for the previous patch: what are the effects of the bug: > > See above. There's many ways the scheduling topology can 'break', resulting in different effects: - scheduling domains might be mixed up to the extent of crashing the bootup - some cores might be missing altogether, reducing available CPUs in essence - cache domains might be seriously mixed up, resulting in serious drop in performance. - or domains might be partitioned 'wrong' but not catastrophically wrong, resulting in a minor performance drop (if at all) ... do we know which of these occurs in this situation? Thanks, Ingo