Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753445AbbDANvP (ORCPT ); Wed, 1 Apr 2015 09:51:15 -0400 Received: from cantor2.suse.de ([195.135.220.15]:55632 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751738AbbDANvN (ORCPT ); Wed, 1 Apr 2015 09:51:13 -0400 Date: Wed, 1 Apr 2015 15:49:13 +0200 From: Borislav Petkov To: Jiri Kosina Cc: linux-edac , "Rafael J. Wysocki" , Len Brown , Tony Luck , Tomasz Nowicki , "Chen, Gong" , Wolfram Sang , Lv Zheng , Naoya Horiguchi , linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, Huang Ying Subject: Re: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader Message-ID: <20150401134913.GB18523@pd.tnic> References: <1427448178-20689-1-git-send-email-bp@alien8.de> <1427448178-20689-6-git-send-email-bp@alien8.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1654 Lines: 41 On Wed, Apr 01, 2015 at 09:45:53AM +0200, Jiri Kosina wrote: > On Fri, 27 Mar 2015, Borislav Petkov wrote: > > > From: Jiri Kosina > > > > Since GHES sources are global, we theoretically need only a single CPU > > reading them per NMI instead of a thundering herd of CPUs waiting on a > > spinlock in NMI context for no reason at all. > > I originally wasn't 100% sure whether GHES sources are global (i.e. if it > really doesn't matter which CPU is reading the registers), but looking at > the code more it actually seems that this is really the right thing to do. > > Rationale: ghes_ioremap_pfn_nmi() always ioremaps() (exclusively) the page > with the registers, performs apei_read() (which is ghes-source specific, > but not CPU-specific) and unmaps the page again. > > There is nothing that would make this CPU-specific. Adding Huang Ying (the > original author of the code) to confirm this. Huang? > > > Do that. > > I think this should indeed be pushed forward. It fixes horrible spinlock > contention on systems which are under NMI storm (such as when perf is > active) unrelated to GHES. Right, so I tested injecting an error without your patch and same behavior. So it all points at global sources AFAICT. It would be cool, though, if someone who knows the fw confirms unambiguously. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/