From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102007 invoked by alias); 27 Mar 2017 18:59:16 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 101994 invoked by uid 89); 27 Mar 2017 18:59:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=2300, Hx-languages-length:2289 X-HELO: mx1.redhat.com DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 6AB1E67BA5 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=longman@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 6AB1E67BA5 Subject: Re: [PATCH v2] rwlock: Fix explicit hand-over. To: Torvald Riegel References: <1490471341.26906.366.camel@redhat.com> <87inmxkt67.fsf@mid.deneb.enyo.de> <1490482860.26906.391.camel@redhat.com> <1490637235.26906.439.camel@redhat.com> <9be4ac93-b326-ad21-b190-5fd4e897dabd@redhat.com> Cc: Florian Weimer , GLIBC Devel , Carlos O'Donell From: Waiman Long Message-ID: <58a61371-e31e-055a-d561-c0e1c13eb7c1@redhat.com> Date: Mon, 27 Mar 2017 18:59:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <9be4ac93-b326-ad21-b190-5fd4e897dabd@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2017-03/txt/msg00643.txt.bz2 On 03/27/2017 02:16 PM, Waiman Long wrote: > On 03/27/2017 01:53 PM, Torvald Riegel wrote: >> On Mon, 2017-03-27 at 12:09 -0400, Waiman Long wrote: >>> On 03/25/2017 07:01 PM, Torvald Riegel wrote: >>>> On Sat, 2017-03-25 at 21:17 +0100, Florian Weimer wrote: >>>>> * Torvald Riegel: >>>>> >>>>>> + bool registered_while_in_write_phase =3D false; >>>>>> if (__glibc_likely ((r & PTHREAD_RWLOCK_WRPHASE) =3D=3D 0)) >>>>>> return 0; >>>>>> + else >>>>>> + registered_while_in_write_phase =3D true; >>>>> Sorry, this doesn't look quite right. Isn't >>>>> registered_while_in_write_phase always true? >>>> Attached is a v2 patch. It's the same logic, but bigger. Most of this >>>> increase is due to reformatting, but I also adapted some of the >>>> comments. >>>> I get two failures, but I guess these are either due to the bad intern= et >>>> connectivity I currently have, or something at the resolver. >>>> FAIL: resolv/mtrace-tst-leaks >>>> FAIL: resolv/tst-leaks >>>> >>>> >>> I have verified that the v2 patch did fix the hang that I saw with my >>> microbenchmark. I also observed an increase in performance in the new >>> rwlock code compared with the old one before the major rewrite. >> Thanks! >> >>> On a >>> 4-socket 40-core 80-thread system, 80 parallel locking threads had an >>> average per-thread throughput of 32,584 ops/s. The old rwlock code had a >>> throughput of 13,411 only. So there is a more than 1.4X increase in >>> performance. >> Is that with the 50% reads / 50% writes workload (per thread), empty >> critical sections, and no delay between critical sections? >> > Yes, I used the default configuration of 1:1 read/write ratio. The > critical section isn't exactly empty as I used 1 pause instruction for > both in the critical section and between critical section. > > Regards, > Longman > Just found out that there is a regression in performance when in writer preferring mode. The average per-thread throughput was 4,733 ops/s with the old glibc, but 2,300 ops/s with the new implementation vs 32,584 ops/s for the reader-preferring mode. It was said in the code that writer-preferring mode isn't the focus in the rewrite. So I am not saying that it is bad, but it is something to keep in mind about. Regards, Longman