threads/167308: Perf regression in thread locking on 8-stable
Rick Reed
rr at whatsapp.com
Thu Apr 26 01:30:10 UTC 2012
>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:
More information about the freebsd-threads
mailing list