From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933037AbbD1CYz (ORCPT ); Mon, 27 Apr 2015 22:24:55 -0400 Received: from mga14.intel.com ([192.55.52.115]:65446 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752849AbbD1CYw (ORCPT ); Mon, 27 Apr 2015 22:24:52 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,661,1422950400"; d="scan'208";a="686611897" From: "Zheng, Lv" To: Borislav Petkov CC: linux-edac , Jiri Kosina , Borislav Petkov , "Rafael J. Wysocki" , "Len Brown" , "Luck, Tony" , Tomasz Nowicki , "Chen, Gong" , Wolfram Sang , Naoya Horiguchi , "linux-acpi@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: RE: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader Thread-Topic: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader Thread-Index: AQHQaG/ro4UZP9zjdEyK4aA7ppX1rp1gX79Q///WlYCAAY9TgIAAHf/g Date: Tue, 28 Apr 2015 02:24:16 +0000 Message-ID: <1AE640813FDE7649BE1B193DEA596E880270F5C8@SHSMSX101.ccr.corp.intel.com> References: <1427448178-20689-1-git-send-email-bp@alien8.de> <1427448178-20689-6-git-send-email-bp@alien8.de> <1AE640813FDE7649BE1B193DEA596E880270F2B2@SHSMSX101.ccr.corp.intel.com> <20150427084631.GA6774@pd.tnic> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id t3S2P0WP016531 Hi, > From: Zheng, Lv > Sent: Tuesday, April 28, 2015 8:44 AM > > Hi, > > > From: Borislav Petkov [mailto:bp@alien8.de] > > Sent: Monday, April 27, 2015 4:47 PM > > > > On Mon, Apr 27, 2015 at 03:16:00AM +0000, Zheng, Lv wrote: > > > > @@ -840,7 +840,9 @@ static int ghes_notify_nmi(unsigned int cmd, struct pt_regs *regs) > > > > struct ghes *ghes; > > > > int sev, ret = NMI_DONE; > > > > > > > > - raw_spin_lock(&ghes_nmi_lock); > > > > + if (!atomic_add_unless(&ghes_in_nmi, 1, 1)) > > > > + return ret; > > > > + > > > > > > Just a simple question. > > > Why not just using cmpxchg here instead of atomic_add_unless so that no atomic_dec will be needed. > > > > What do you think atomic_add_unless ends up doing: > > > > #APP > > # 177 "./arch/x86/include/asm/atomic.h" 1 > > .pushsection .smp_locks,"a" > > .balign 4 > > .long 671f - . > > .popsection > > 671: > > lock; cmpxchgl %edx,ghes_in_nmi(%rip) # D.37056, MEM[(volatile u32 *)&ghes_in_nmi] > > # 0 "" 2 > > #NO_APP > > > > And you need to atomic_dec() so that another reader can enter, i.e. how > > the exclusion primitive works. > > > > Or did you have something else in mind? > > My mistake. > I mean cmpxchg() and xchg() (or atomic_cmpxchg() and atomic_xchg()) pair here, so nothing can be reduced. Let me correct, it should be atomic_cmpxchg() and atomic_set() here as you only need to switch between 0 and 1. Sorry for the noise. Thanks and best regards -Lv > > But IMO, atomic_add_unless() is implemented via cmpxchg on many architectures. > And it might be better to use it directly here which is a bit faster as you actually only need one value switch here. > > Thanks and best regards > -Lv > > > > > > -- > > Regards/Gruss, > > Boris. > > > > ECO tip #101: Trim your mails when you reply. > > -- {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I