Date: Thu, 26 Apr 2012 01:20:26 GMT From: Rick Reed <rr@whatsapp.com> To: freebsd-gnats-submit@FreeBSD.org Subject: threads/167308: Perf regression in thread locking on 8-stable Message-ID: <201204260120.q3Q1KQCT006764@red.freebsd.org> Resent-Message-ID: <201204260130.q3Q1U9DO099233@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 167308 >Category: threads >Synopsis: Perf regression in thread locking on 8-stable >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-threads >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Apr 26 01:30:09 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Rick Reed >Release: 8.3-STABLE (cvsup @4/17/12 1300) >Organization: WhatsApp Inc. >Environment: 8.3-STABLE amd64 >Description: Rev 234373 causes a significant performance regression for our Erlang-based application. I don't know what the direct results of the change are, but it manifests as abnormal amounts of contention for a particular global lock among the scheduler threads (one per CPU) in the Erlang VM under significant load. Backing this change out results in normal contention and performance. I see there's new code using WAKE2 in HEAD & 9, but I'm not sure how you balance the correctness issue in the stated case of unlock() then destroy() versus the significant impact to performance for apps which don't do that. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201204260120.q3Q1KQCT006764>