From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3F5B6C433DB for ; Wed, 17 Mar 2021 13:38:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F1AB764F4F for ; Wed, 17 Mar 2021 13:38:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231184AbhCQNiC (ORCPT ); Wed, 17 Mar 2021 09:38:02 -0400 Received: from mail.kernel.org ([198.145.29.99]:40114 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229809AbhCQNhf (ORCPT ); Wed, 17 Mar 2021 09:37:35 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id BA56664F30; Wed, 17 Mar 2021 13:37:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1615988255; bh=uWLJjwbt6az/G89gyUZnzcahOeBXUQO6+rfQjVIDj6k=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=EMqyfriSWDNrf/7PyPyKwWWl/3YPWhVm9DiAyznVOTgjDzow4BkdbFWl2MELdc9WD 6LJ4OU0u23fUNXVNzCmuV0jILKAaL7vXK1yWhmQqlNJDS7/SF3GlFsQu60Q45kGLOs XQ52BZ3y2P58FfSOmMCr4I7/QqlE2/IUL8RYj0yVHajXBZrSLtMkiN7MXe0D0jU7sL 8lABUzQHSyu8tuH0WFoUUlyltpNUgpjUltj2iK2Y7ApzyVzITwLA+FmddXqoXiyICd EONEj/MvwwJbIpLZSjYHlQZPCRHgbjuutGWAkCll1QFlTYvOv49Ek72nBLoQtEga2s ftDzLl9NH5L0g== Received: by quaco.ghostprotocols.net (Postfix, from userid 1000) id 80C4C40647; Wed, 17 Mar 2021 10:37:31 -0300 (-03) Date: Wed, 17 Mar 2021 10:37:31 -0300 From: Arnaldo Carvalho de Melo To: Alexander Monakov Cc: Peter Zijlstra , Ingo Molnar , Kim Phillips , Jiri Olsa , Borislav Petkov , Tom Lendacky , x86@kernel.org, lkml , Alexander Shishkin , Stanislav Kozina , Michael Petlan , Pierre Amadio , onatalen@redhat.com, darcari@redhat.com, "Rafael J. Wysocki" Subject: Re: unknown NMI on AMD Rome Message-ID: References: <36397980-f897-147f-df55-f37805d869c9@amd.com> <20210317084829.GA474581@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Url: http://acmel.wordpress.com Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Wed, Mar 17, 2021 at 04:32:17PM +0300, Alexander Monakov escreveu: > On Wed, 17 Mar 2021, Peter Zijlstra wrote: > > On Wed, Mar 17, 2021 at 09:48:29AM +0100, Ingo Molnar wrote: > > > > https://developer.amd.com/wp-content/resources/56323-PUB_0.78.pdf > > > 1215 IBS (Instruction Based Sampling) Counter Valid Value > > > May be Incorrect After Exit From Core C6 (CC6) State > > > Description > > > If a core's IBS feature is enabled and configured to generate an interrupt, including NMI (Non-Maskable > > > Interrupt), and the IBS counter overflows during the entry into the Core C6 (CC6) state, the interrupt may be > > > issued, but an invalid value of the valid bit may be restored when the core exits CC6. > > > Potential Effect on System > > > The operating system may receive interrupts due to an IBS counter event, including NMI, and not observe an > > > valid IBS register. Console messages indicating "NMI received for unknown reason" have been observed on > > > Linux systems. > > > Suggested Workaround: None > > > Fix Planned: No fix planned > > Should be simple enough to disable CC6 while IBS is in use. Kim, can you > > please make that happen? > Wouldn't that "magically" significantly speed up workloads running under > 'perf top', in case they don't saturate the CPUs? Scheduling gets > much snappier if the target CPU doesn't need to wake up from deep sleep :) > Alternatively, would you consider adding the errata reference to the > printk message when IBS is in use, and rate-limit it so it doesn't > flood dmesg? Then the user will know what's going on, and may > choose to temporarily disable C-states using the 'cpupower' tool. Would be interesting as well to make 'perf top' realize that somehow (looking at some cpu id, etc) and don't use IBS when C-states are being used and/or warn the user about the situation, i.e. cycles:P can't be used in this machine if C-states are enabled? - Arnaldo