From owner-freebsd-threads@FreeBSD.ORG Thu Apr 26 01:30:10 2012 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EEDE1065670 for ; Thu, 26 Apr 2012 01:30:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DC7148FC15 for ; Thu, 26 Apr 2012 01:30:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q3Q1U93l099234 for ; Thu, 26 Apr 2012 01:30:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3Q1U9DO099233; Thu, 26 Apr 2012 01:30:09 GMT (envelope-from gnats) Resent-Date: Thu, 26 Apr 2012 01:30:09 GMT Resent-Message-Id: <201204260130.q3Q1U9DO099233@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-threads@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Rick Reed Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F7A61065672 for ; Thu, 26 Apr 2012 01:20:27 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id EF5DF8FC0C for ; Thu, 26 Apr 2012 01:20:26 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id q3Q1KQix006765 for ; Thu, 26 Apr 2012 01:20:26 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id q3Q1KQCT006764; Thu, 26 Apr 2012 01:20:26 GMT (envelope-from nobody) Message-Id: <201204260120.q3Q1KQCT006764@red.freebsd.org> Date: Thu, 26 Apr 2012 01:20:26 GMT From: Rick Reed To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: threads/167308: Perf regression in thread locking on 8-stable X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 01:30:10 -0000 >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: