This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2] rwlock: Fix explicit hand-over.
- From: Torvald Riegel <triegel at redhat dot com>
- To: Waiman Long <longman at redhat dot com>
- Cc: Florian Weimer <fw at deneb dot enyo dot de>, GLIBC Devel <libc-alpha at sourceware dot org>, Carlos O'Donell <codonell at redhat dot com>
- Date: Mon, 27 Mar 2017 19:53:55 +0200
- Subject: Re: [PATCH v2] rwlock: Fix explicit hand-over.
- Authentication-results: sourceware.org; auth=none
- 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=triegel at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 5F9B96DDBB
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5F9B96DDBB
- References: <1490471341.26906.366.camel@redhat.com> <87inmxkt67.fsf@mid.deneb.enyo.de> <1490482860.26906.391.camel@redhat.com> <c8fe83ad-68cc-5b16-19f8-64e534c9a2b6@redhat.com>
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 = false;
> >>> if (__glibc_likely ((r & PTHREAD_RWLOCK_WRPHASE) == 0))
> >>> return 0;
> >>> + else
> >>> + registered_while_in_write_phase = 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 internet
> > 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?