From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Zheng, Lv" Subject: RE: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader Date: Thu, 30 Apr 2015 08:05:12 +0000 Message-ID: <1AE640813FDE7649BE1B193DEA596E8802712130@SHSMSX101.ccr.corp.intel.com> References: <1427448178-20689-1-git-send-email-bp@alien8.de> <1427448178-20689-6-git-send-email-bp@alien8.de> <1AE640813FDE7649BE1B193DEA596E880270F835@SHSMSX101.ccr.corp.intel.com> <20150428135913.GD19025@pd.tnic> <1AE640813FDE7649BE1B193DEA596E880270FB3B@SHSMSX101.ccr.corp.intel.com> <20150429081355.GA5498@pd.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mga09.intel.com ([134.134.136.24]:27674 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750808AbbD3IFU (ORCPT ); Thu, 30 Apr 2015 04:05:20 -0400 In-Reply-To: <20150429081355.GA5498@pd.tnic> Content-Language: en-US Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org 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" SGksDQoNCj4gRnJvbTogQm9yaXNsYXYgUGV0a292IFttYWlsdG86YnBAYWxpZW44LmRlXQ0KPiBT ZW50OiBXZWRuZXNkYXksIEFwcmlsIDI5LCAyMDE1IDQ6MTQgUE0NCj4gU3ViamVjdDogUmU6IFtS RkMgUEFUQ0ggNS81XSBHSEVTOiBNYWtlIE5NSSBoYW5kbGVyIGhhdmUgYSBzaW5nbGUgcmVhZGVy DQo+IA0KPiBPbiBXZWQsIEFwciAyOSwgMjAxNSBhdCAxMjo0OTo1OUFNICswMDAwLCBaaGVuZywg THYgd3JvdGU6DQo+ID4gPiA+IFdlIGFic29sdXRlbHkgd2FudCB0byB1c2UgYXRvbWljX2FkZF91 bmxlc3MoKSBiZWNhdXNlIHdlIGdldCB0byBzYXZlIHVzDQo+ID4gPiA+IHRoZSBleHBlbnNpdmUN Cj4gPiA+ID4NCj4gPiA+ID4gCUxPQ0s7IENNUFhDSEcNCj4gPiA+ID4NCj4gPiA+ID4gaWYgdGhl IHZhbHVlIHdhcyBhbHJlYWR5IDEuIFdoaWNoIGlzIGV4YWN0bHkgd2hhdCB0aGlzIHBhdGNoIGlz IHRyeWluZw0KPiA+ID4gPiB0byBhdm9pZCAtIGEgdGh1bmRlcmluZyBoZXJkIG9mIGNvcmVzIENN UFhDSEdpbmcgYSBnbG9iYWwgdmFyaWFibGUuDQo+ID4gPg0KPiA+ID4gSU1PLCBvbiBtb3N0IGFy Y2hpdGVjdHVyZXMsIHRoZSAiY21wIiBwYXJ0IHNob3VsZCB3b3JrIGp1c3QgbGlrZSB3aGF0IHlv dSd2ZSBkb25lIHdpdGggImlmIi4NCj4gPiA+IEFuZCBvbiBzb21lIGFyY2hpdGVjdHVyZXMsIGlm IHRoZSAieGNoZyIgZG9lc24ndCBoYXBwZW4sIHRoZSAiY21wIiBwYXJ0IGV2ZW4gd29uJ3QgY2F1 c2UgYSBwaXBlIGxpbmUgaGF6YXJkLg0KPiANCj4gRXZlbiBpZiBDTVBYQ0hHIGlzIGJlaW5nIHNw bGl0IGludG8gc2V2ZXJhbCBtaWNyb29wcywgdGhleSBhbGwgc3RpbGwNCj4gbmVlZCB0byBmbG93 IGRvd24gdGhlIHBpcGUgYW5kIHJlcXVpcmUgcmVzb3VyY2VzIGFuZCB0cmFja2luZy4gQW5kIHlv dQ0KPiBvbmx5IGtub3cgYXQgcmV0aXJlIHRpbWUgd2hhdCB0aGUgQ01QIHJlc3VsdCBpcyBhbmQg Y2FuICJkaXNjYXJkIiB0aGUNCj4gWENIRyBwYXJ0LiBQcm92aWRlZCB0aGUgdWFyY2ggaXMgc21h cnQgZW5vdWdoIHRvIGRvIHRoYXQuDQo+IA0KPiBUaGlzIGlzIHByb2JhYmx5IHdoeSBDTVBYQ0hH IG5lZWRzIDUsNiw3LDEwLDIyLC4uLiBjeWNsZXMgZGVwZW5kaW5nIG9uDQo+IHVhcmNoIGFuZCB2 ZW5kb3IsIGlmIEkgY2FuIHRydXN0IEFnbmVyIEZvZydzIHRhYmxlcy4gQW5kIEkgYmV0IHRob3Nl DQo+IG51bWJlcnMgYXJlIGJlc3QtY2FzZSBvbmx5IGFuZCBpbiByZWFsLWxpZmUgdGhleSBwcm9i YWJseSB0ZW5kIHRvIGZhbGwNCj4gb3V0IGV2ZW4gd29yc2UuDQo+IA0KPiBDTVAgbmVlZHMgb25s eSAxLiBPbiBhbG1vc3QgZXZlcnkgdWFyY2ggYW5kIHZlbmRvci4gQW5kIGV2ZW4gdGhhdCBjeWNs ZQ0KPiBwcm9iYWJseSBnZXRzIGhpZGRlbiB3aXRoIGEgZ29vZCBicmFuY2ggcHJlZGljdG9yLg0K DQpBcmUgdGhlcmUgYW55IHN1Y2ggZGF0YSBhcm91bmQgdGhlIFNDIGFuZCBMTCAoTUlQUyk/DQoN Cj4gDQo+ID4gSWYgeW91IG1hbiB0aGUgTE9DSyBwcmVmaXgsIEkgdW5kZXJzdGFuZCBub3cuDQo+ IA0KPiBBbmQgdGhhdCBtYWtlcyBzZXZlcmFsIHRpbWVzIHdvcnNlOiAyMiwgNDAsIDgwLCAuLi4g Y3ljbGVzLg0KDQpJJ20gT0sgaWYgdGhlIGNvZGUgc3RpbGwga2VlcHMgdGhlIHJlYWRhYmlsaXR5 IHRoZW4uDQoNClRoYW5rcyBhbmQgYmVzdCByZWdhcmRzDQotTHYNCg0KPiANCj4gLS0NCj4gUmVn YXJkcy9HcnVzcywNCj4gICAgIEJvcmlzLg0KPiANCj4gRUNPIHRpcCAjMTAxOiBUcmltIHlvdXIg bWFpbHMgd2hlbiB5b3UgcmVwbHkuDQo+IC0tDQo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751193AbbD3IFa (ORCPT ); Thu, 30 Apr 2015 04:05:30 -0400 Received: from mga09.intel.com ([134.134.136.24]:27674 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750808AbbD3IFU (ORCPT ); Thu, 30 Apr 2015 04:05:20 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,675,1422950400"; d="scan'208";a="687894510" 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/ro4UZP9zjdEyK4aA7ppX1rp1imlXQ//+FsoCAATPzQIAAB3pA///2boCAAhVQ0A== Date: Thu, 30 Apr 2015 08:05:12 +0000 Message-ID: <1AE640813FDE7649BE1B193DEA596E8802712130@SHSMSX101.ccr.corp.intel.com> References: <1427448178-20689-1-git-send-email-bp@alien8.de> <1427448178-20689-6-git-send-email-bp@alien8.de> <1AE640813FDE7649BE1B193DEA596E880270F835@SHSMSX101.ccr.corp.intel.com> <20150428135913.GD19025@pd.tnic> <1AE640813FDE7649BE1B193DEA596E880270FB3B@SHSMSX101.ccr.corp.intel.com> <20150429081355.GA5498@pd.tnic> In-Reply-To: <20150429081355.GA5498@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 t3U85Yju031633 Hi, > From: Borislav Petkov [mailto:bp@alien8.de] > Sent: Wednesday, April 29, 2015 4:14 PM > Subject: Re: [RFC PATCH 5/5] GHES: Make NMI handler have a single reader > > On Wed, Apr 29, 2015 at 12:49:59AM +0000, Zheng, Lv wrote: > > > > We absolutely want to use atomic_add_unless() because we get to save us > > > > the expensive > > > > > > > > LOCK; CMPXCHG > > > > > > > > if the value was already 1. Which is exactly what this patch is trying > > > > to avoid - a thundering herd of cores CMPXCHGing a global variable. > > > > > > IMO, on most architectures, the "cmp" part should work just like what you've done with "if". > > > And on some architectures, if the "xchg" doesn't happen, the "cmp" part even won't cause a pipe line hazard. > > Even if CMPXCHG is being split into several microops, they all still > need to flow down the pipe and require resources and tracking. And you > only know at retire time what the CMP result is and can "discard" the > XCHG part. Provided the uarch is smart enough to do that. > > This is probably why CMPXCHG needs 5,6,7,10,22,... cycles depending on > uarch and vendor, if I can trust Agner Fog's tables. And I bet those > numbers are best-case only and in real-life they probably tend to fall > out even worse. > > CMP needs only 1. On almost every uarch and vendor. And even that cycle > probably gets hidden with a good branch predictor. Are there any such data around the SC and LL (MIPS)? > > > If you man the LOCK prefix, I understand now. > > And that makes several times worse: 22, 40, 80, ... cycles. I'm OK if the code still keeps the readability then. 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