From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 640FCC300 for ; Tue, 2 Jun 2015 15:17:10 +0200 (CEST) MIME-Version: 1.0 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga102.fm.intel.com with ESMTP; 02 Jun 2015 06:17:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,539,1427785200"; d="p7s'?scan'208";a="703924184" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by orsmga001.jf.intel.com with ESMTP; 02 Jun 2015 06:17:08 -0700 Received: from irsmsx110.ger.corp.intel.com ([169.254.15.124]) by IRSMSX101.ger.corp.intel.com ([169.254.1.217]) with mapi id 14.03.0224.002; Tue, 2 Jun 2015 14:17:07 +0100 From: "Dementiev, Roman" To: "dev@dpdk.org" Thread-Topic: add support for HTM lock elision for x86 Thread-Index: AdCdNmfqgwc0p3T9SdiVV1MRdo/Isw== Date: Tue, 2 Jun 2015 13:17:07 +0000 Message-ID: <4EB94430E0E05A4EAE258E2A9A1B98DD33EAE0D3@irsmsx110.ger.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.182] MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] add support for HTM lock elision for x86 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 13:17:11 -0000 Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052 >From rolette@infiniteio.com Tue Jun 2 15:21:24 2015 Return-Path: Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by dpdk.org (Postfix) with ESMTP id B03FBBDC2 for ; Tue, 2 Jun 2015 15:21:24 +0200 (CEST) Received: by wizo1 with SMTP id o1so144374926wiz.1 for ; Tue, 02 Jun 2015 06:21:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EZ5V09Uf0HqR5pepp3xmM2K+ESwvO6YmUxphj1p/FH4=; b=KSmNxWms+vaLWfI43mVrAVKs9hjo5OOHZj8i/fWcPZBQdx7OF1WZqsohu1JQL/p5c2 4wxywVCESWJefU+OtJ4aluXRwJMbKZaX6KGPS9yNIEkXffuZhxri5VkEzyig3Cz6FzZg vMEvsEiVcO3b40xPZ/KtVENZ1AXE48EeeXwvlcpKNzbSittMT2qxJvWqIFtWIhHyZz2G LXZ7WdpwSYhyobXxFX/kMMe2n/qDqlAvgo+pIgf0jZdJVBTqz/2Mx8MdJQlCz2BQbzpv KyylO/bE46ktW7D8eQVKtBMtykrW1svCYCebSYLEiWD9PA/Mlq+g59HV7uOBjpR0LRag JHDw== X-Gm-Message-State: ALoCoQnTMgOKUua0wm5br0wzyd2vyF1dbh6JeCzRCh1zTNb0jX61HFls8jGfZRV8ah0sjrcDwWll MIME-Version: 1.0 X-Received: by 10.195.18.8 with SMTP id gi8mr11293724wjd.153.1433251284551; Tue, 02 Jun 2015 06:21:24 -0700 (PDT) Received: by 10.194.36.193 with HTTP; Tue, 2 Jun 2015 06:21:24 -0700 (PDT) In-Reply-To: <1433250693-23644-1-git-send-email-roman.dementiev@intel.com> References: <1433250693-23644-1-git-send-email-roman.dementiev@intel.com> Date: Tue, 2 Jun 2015 08:21:24 -0500 Message-ID: From: Jay Rolette To: Roman Dementiev Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: DPDK Subject: Re: [dpdk-dev] add support for HTM lock elision for x86 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 13:21:24 -0000 On Tue, Jun 2, 2015 at 8:11 AM, Roman Dementiev wrote: > > This series of patches adds methods that use hardware memory transactions > (HTM) > on fast-path for DPDK locks (a.k.a. lock elision). Here the methods are > implemented > for x86 using Restricted Transactional Memory instructions (Intel(r) > Transactional > Synchronization Extensions). The implementation fall-backs to the normal > DPDK lock > if HTM is not available or memory transactions fail. > This is very interesting. Do you have any summary you can give us of what the performance implications are from your test data? > This is not a replacement for lock usages since not all critical sections > protected > by locks are friendly to HTM. > Any pointers to material that describe where HTM in its current incarnation on x86 is approprate? > > Roman Dementiev (3): > spinlock: add support for HTM lock elision for x86 > rwlock: add support for HTM lock elision for x86 > test scaling of HTM lock elision protecting rte_hash > > app/test/Makefile | 1 + > app/test/test_hash_scaling.c | 223 > +++++++++++++++++++++ > lib/librte_eal/common/Makefile | 4 +- > .../common/include/arch/ppc_64/rte_rwlock.h | 38 ++++ > .../common/include/arch/ppc_64/rte_spinlock.h | 41 ++++ > lib/librte_eal/common/include/arch/x86/rte_rtm.h | 73 +++++++ > .../common/include/arch/x86/rte_rwlock.h | 82 ++++++++ > .../common/include/arch/x86/rte_spinlock.h | 107 ++++++++++ > lib/librte_eal/common/include/generic/rte_rwlock.h | 194 > ++++++++++++++++++ > .../common/include/generic/rte_spinlock.h | 75 +++++++ > lib/librte_eal/common/include/rte_rwlock.h | 158 --------------- > 11 files changed, 836 insertions(+), 160 deletions(-) > Thanks! Jay