From patchwork Thu Feb 23 13:34:23 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Torvald Riegel X-Patchwork-Id: 142613 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 651E2B6EE8 for ; Fri, 24 Feb 2012 00:34:53 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1330608897; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Subject:From:To:Cc:Content-Type:Date:Message-ID:Mime-Version: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=4oj5AHo37wCikXetbPfM sSkW4eQ=; b=jg+vpaN2ToRZQP5fvdtRzwLWUxabadp7PZwlf5DSJ1zWUtjBfjWg 26BLADAJFcVdoDMAjC7FC7mL2aD/TT7Ft6tT2i44QP/QpZyBcYHdJNDSC0PNpw0S u5g2mFFg8zm/KU73Z8CmWgZhKLSe+l9oYXSunoWcc9zMDBGp11bQ2C0= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Subject:From:To:Cc:Content-Type:Date:Message-ID:Mime-Version:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=KZNeyEMhHqBxltdFHOa1pwdVm+0hNXlOZyn08SpLN/Wx6doZiuEL8ayGZLa/V3 v55m42tWfCEKoTb4rp35KaEoJAiB/vKPy4XuCIpJazZV2Q2oOZMt2nxvrscQVFG/ C3uH4OXnde8VNWj571qwMf0eRXFaZUky2qdtVumA4kq9A=; Received: (qmail 14910 invoked by alias); 23 Feb 2012 13:34:46 -0000 Received: (qmail 14265 invoked by uid 22791); 23 Feb 2012 13:34:45 -0000 X-SWARE-Spam-Status: No, hits=-6.7 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_HI, SPF_HELO_PASS, TW_TX, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 23 Feb 2012 13:34:28 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q1NDYSTb008972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 23 Feb 2012 08:34:28 -0500 Received: from [10.36.6.208] (vpn1-6-208.ams2.redhat.com [10.36.6.208]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q1NDYQ2K024459; Thu, 23 Feb 2012 08:34:27 -0500 Subject: libitm: Use ml_wt as default TM methods for >1 thread. From: Torvald Riegel To: GCC Patches Cc: Richard Henderson , Aldy Hernandez Date: Thu, 23 Feb 2012 14:34:23 +0100 Message-ID: <1330004063.2986.2789.camel@triegel.csb> Mime-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org This patch changes the default TM method that is used if more than one thread is registered to ml_wt (from serialirr_onwrite previously). For one registered thread, it's still serialirr. Right now, this will not be a performance advantage for every workload and number of threads. However, of the TM methods we have implemented so far, ml_wt is the only one that allows concurrent update transactions. gl_wt update txns essentially abort all other txns that have read something. serialirr_onwrite serializes all update txns. ml_wt can execute disjoint-access-parallel txns in parallel, unless we get false sharing via the address-to-orec mapping. Therefore, even though ml_wt performance isn't great currently, it's the only option that doesn't suffer from a principal scalability bottleneck. In the long-term, this should get improved by a less trivial choice regarding which TM method to use (e.g., based on actual abort rate and other factors). Likewise, the ml_wt lock-mapping can hopefully be improved, so that we can at least get better scalability even if the single-thread overheads are higher. We might also want to add other TM methods. But all of that will require some time to get done, so until then, I think the better choice right now is still to go with ml_wt as-is in the meantime. OK? PS: I also noticed that libitm/testsuite/libitm.c/memcpy-1.c takes surprisingly long when using ml_wt compared to serialirr. I will investigate this later. commit ce7f7cd1797cb3c4136c53ff038d2f8f7f0bfad7 Author: Torvald Riegel Date: Thu Feb 23 14:16:14 2012 +0100 libitm: Use ml_wt as default TM methods for >1 thread. libitm/ * retry.cc (GTM::gtm_thread::number_of_threads_changed): Change default dispatch for more than 1 thread to ml_wt. diff --git a/libitm/retry.cc b/libitm/retry.cc index 2c1483e..660bf52 100644 --- a/libitm/retry.cc +++ b/libitm/retry.cc @@ -314,7 +314,7 @@ GTM::gtm_thread::number_of_threads_changed(unsigned previous, unsigned now) set_default_dispatch(default_dispatch_user); else { - abi_dispatch* a = dispatch_serialirr_onwrite(); + abi_dispatch* a = dispatch_ml_wt(); if (a->supports(now)) set_default_dispatch(a); else