From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932242AbdCFSgx (ORCPT ); Mon, 6 Mar 2017 13:36:53 -0500 Received: from relay1.sgi.com ([192.48.180.66]:50743 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753575AbdCFSgT (ORCPT ); Mon, 6 Mar 2017 13:36:19 -0500 X-Greylist: delayed 585 seconds by postgrey-1.27 at vger.kernel.org; Mon, 06 Mar 2017 13:36:19 EST Message-Id: <20170306181737.494819741@asylum.americas.sgi.com> References: <20170306181737.059578494@asylum.americas.sgi.com> User-Agent: quilt/0.46-1 Date: Mon, 06 Mar 2017 12:17:39 -0600 From: Mike Travis To: Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , Don Zickus , Peter Zijlstra Cc: Dimitri Sivanich , Frank Ramsay , Russ Anderson , Tony Ernst , x86@kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 2/2] x86/platform/uv: Use low priority low frequency NMI call chain Content-Disposition: inline; filename=uv_use_nmi_remote Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Use the new NMI call chain NMI_LAST instead of the NMI_UNKNOWN call chain to eliminate the WARNING message about having multiple NMI handlers registering on the NMI UNKNOWN call chain. This "call only when not already claimed by another NMI handler" is required as the UV architecture cannot sustain a high rate of reads to the MMR's on the UV HUB's to verify if the NMI should be claimed. This not only slows down the system responsiveness, it can result in a system lockup. Signed-off-by: Mike Travis Reviewed-by: Russ Anderson --- arch/x86/platform/uv/uv_nmi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- linux-4.4.orig/arch/x86/platform/uv/uv_nmi.c +++ linux-4.4/arch/x86/platform/uv/uv_nmi.c @@ -53,7 +53,7 @@ * disrupts the UV Hub's primary mission of directing NumaLink traffic and * can cause system problems to occur. * - * To do this we register our primary NMI notifier on the NMI_UNKNOWN + * To do this we register our primary NMI notifier on the NMI_LAST * chain. This reduces the number of false NMI calls when the perf * tools are running which generate an enormous number of NMIs per * second (~4M/s for 1024 CPU threads). Our secondary NMI handler is @@ -992,7 +992,7 @@ static int uv_handle_nmi_ping(unsigned i static void uv_register_nmi_notifier(void) { - if (register_nmi_handler(NMI_UNKNOWN, uv_handle_nmi, 0, "uv")) + if (register_nmi_handler(NMI_LAST, uv_handle_nmi, 0, "uv")) pr_warn("UV: NMI handler failed to register\n"); if (register_nmi_handler(NMI_LOCAL, uv_handle_nmi_ping, 0, "uvping")) --