From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932238AbbD1AoV (ORCPT ); Mon, 27 Apr 2015 20:44:21 -0400 Received: from mga03.intel.com ([134.134.136.65]:29586 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752597AbbD1AoS (ORCPT ); Mon, 27 Apr 2015 20:44:18 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,660,1422950400"; d="scan'208";a="716770616" 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///WlYCAAY9TgA== Date: Tue, 28 Apr 2015 00:44:12 +0000 Message-ID: <1AE640813FDE7649BE1B193DEA596E880270F55F@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> In-Reply-To: <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 t3S0iQ9M016337 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. 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