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

[Rick Reed]

>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: