From patchwork Fri Mar 30 07:14:53 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: kemi X-Patchwork-Id: 893129 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=sourceware.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=libc-alpha-return-91303-incoming=patchwork.ozlabs.org@sourceware.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=intel.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="TrZY6ZPN"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 40CCcj3TKYz9s16 for ; Fri, 30 Mar 2018 18:17:41 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:date:message-id:in-reply-to :references; q=dns; s=default; b=R/p4pZR3goio1nNd/KN9IEisN6E3xjF wknprn3cGVPJPpzMvSAYzbFG2vxn39FEixH8IeTSnz+ox6y45Vt59UEuTjSpXhQV JOLQO7BFw1+PaWwEanKZkrs29LdUC8bHuDSd3w8+7J7LDDdG0b8l6vIwGPqVTb7q OBwgUVHhqx2I= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:date:message-id:in-reply-to :references; s=default; bh=voVkQDHoicvc4uQTVhkzfdG4j3I=; b=TrZY6 ZPNlk//yrtiHelU+84SmYSJ8SjC8JlR9PloM9qMzyEE5sd0qmScfutn6IhU8U963 B0Tx3Pz0zDgKCItwfHzC4S1gewjKS3EcV6t86ZXY6eNaSGbzGXvAM8tj5OU0ZPVA waN1+lutRsDp4SHRo8daXrhwAu/Bjmz67M2ckA= Received: (qmail 84404 invoked by alias); 30 Mar 2018 07:17:19 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 84259 invoked by uid 89); 30 Mar 2018 07:17:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=0.5 X-HELO: mga07.intel.com X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 From: Kemi Wang To: Glibc alpha Cc: Dave Hansen , Tim Chen , Andi Kleen , Ying Huang , Aaron Lu , Lu Aubrey , Kemi Wang Subject: [PATCH 3/3] Mutex: Avoid useless spinning Date: Fri, 30 Mar 2018 15:14:53 +0800 Message-Id: <1522394093-9835-3-git-send-email-kemi.wang@intel.com> In-Reply-To: <1522394093-9835-1-git-send-email-kemi.wang@intel.com> References: <1522394093-9835-1-git-send-email-kemi.wang@intel.com> Usually, we can't set too short time out while spinning on the lock, that probably makes a thread which is trying to acquire the lock go to sleep quickly, thus weakens the benefit of pthread adaptive spin lock. However, there is also a problem if we set the time out large in case of protecting a small critical section with severe lock contention. As we can see the test result in the last patch, the performance is highly effected by the spin count tunables, smaller spin count, better performance improvement. This is because the thread probably spins on the lock until timeout in severe lock contention before going to sleep. In this patch, we avoid the useless spin by making the spinner sleep if it fails to acquire the lock when the lock is available, as suggested by Tim Chen. nr_threads base COUNT=1000(head~1) COUNT=1000(head) 1 51644585 51323778(-0.6%) 51378551(-0.5%) 2 7914789 9867343(+24.7%) 11503559(+45.3%) 7 1687620 3430504(+103.3%) 7817383(+363.2%) 14 1026555 1843458(+79.6%) 7360883(+617.0%) 28 962001 681965(-29.1%) 5681945(+490.6%) 56 883770 364879(-58.7%) 3416068(+286.5%) 112 1150589 415261(-63.9%) 3255700(+183.0%) Suggested-by: Tim Chen Signed-off-by: Kemi Wang --- nptl/pthread_mutex_lock.c | 25 +++++++++++-------------- 1 file changed, 11 insertions(+), 14 deletions(-) diff --git a/nptl/pthread_mutex_lock.c b/nptl/pthread_mutex_lock.c index c3aca93..0faee1a 100644 --- a/nptl/pthread_mutex_lock.c +++ b/nptl/pthread_mutex_lock.c @@ -127,22 +127,19 @@ __pthread_mutex_lock (pthread_mutex_t *mutex) int cnt = 0; int max_cnt = MIN (__mutex_aconf.spin_count, mutex->__data.__spins * 2 + 100); + + /* MO read while spinning */ do - { - if (cnt >= max_cnt) - { - LLL_MUTEX_LOCK (mutex); - break; - } - /* MO read while spinning */ - do - { - atomic_spin_nop (); - } - while (atomic_load_relaxed (&mutex->__data.__lock) != 0 && + { + atomic_spin_nop (); + } + while (atomic_load_relaxed (&mutex->__data.__lock) != 0 && ++cnt < max_cnt); - } - while (LLL_MUTEX_TRYLOCK (mutex) != 0); + /* Try to acquire the lock if lock is available or the spin count + * is run out, go to sleep if fails + */ + if (LLL_MUTEX_TRYLOCK (mutex) != 0) + LLL_MUTEX_LOCK (mutex); mutex->__data.__spins += (cnt - mutex->__data.__spins) / 8; }