threads/167308: Perf regression in thread locking on 8-stable

Rick Reed rr at
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
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Apr 26 01:30:09 UTC 2012
>Originator:     Rick Reed
>Release:        8.3-STABLE (cvsup @4/17/12 1300)
WhatsApp Inc.
8.3-STABLE amd64
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.




More information about the freebsd-threads mailing list