From patchwork Thu May 25 05:26:33 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Shi X-Patchwork-Id: 100462 Delivered-To: patch@linaro.org Received: by 10.140.96.100 with SMTP id j91csp609531qge; Wed, 24 May 2017 22:30:01 -0700 (PDT) X-Received: by 10.99.63.141 with SMTP id m135mr42958342pga.195.1495690201397; Wed, 24 May 2017 22:30:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1495690201; cv=none; d=google.com; s=arc-20160816; b=n5XqwWfwiacuYgw7hj4xjJ17HNCi/4QyaS4+7gEzBvJ1uVA/oTCklyLj4L09jD/kLa zX7LnYWnP4pTfCthSlQdcfxAsMLeAxrs4nHBJFOxqAQzc3eJVxoRnF+AfyZduSTTntsY seAWbQj6F+P8QB0Iyj+vP2zKIV2hWF654F3A6yiqxUHQ/yt7vcu41kTq0lutpveXwMXs lIwOxMxBubjjA9dTK8X1Xj5lL77+WDbs3RehIClJ/tBfAbt88KJ+xCOieyJlEJgNV3ZO LoA0ckBeqOZ4jqAs+1KnBfxW7zuh6hTH24QXVMX3o93TZpPbAkyAYteGAXWMfZgtzLib /Xcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=UXAyyPgeVtlunpYIMmBjubXgueedm76oEyvtTdN6kvE=; b=P9woamivsvoO3cp5fTXbDrLp+BD0EbCVQ9C1IR7+yqJwrRRtkM+0HFANIyHFdh8PZW 5CBIUxGBf69m53ww5Idjw0E8YwnGP53eDgi0x8HZ5GQ+y1+nBVxzxfcB6fNA6ED6tp3S zH70tpOSfsr8EPKBEUqLObBDl/x9nClE59VHI6b50du+cYcA5VGZ8FZsgnJuuN6zLOM3 22uUBEIiglAXAmNKP/QKeKilnNN2F75tJ0XlaPyY1swCBxbf22YsDu2BTn3rq2V78Zfe n0YkChDidvlmIRJEe2ON8l1Y7l9OvkoTY7npRoOMU0eBWVK18q1DFTWBZ54jMHCBKTwy v04A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l10si26907631plk.133.2017.05.24.22.30.01; Wed, 24 May 2017 22:30:01 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1032403AbdEYF3m (ORCPT + 25 others); Thu, 25 May 2017 01:29:42 -0400 Received: from mail-pf0-f178.google.com ([209.85.192.178]:35591 "EHLO mail-pf0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S941943AbdEYF3K (ORCPT ); Thu, 25 May 2017 01:29:10 -0400 Received: by mail-pf0-f178.google.com with SMTP id n23so156515581pfb.2 for ; Wed, 24 May 2017 22:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=UXAyyPgeVtlunpYIMmBjubXgueedm76oEyvtTdN6kvE=; b=FXwklRpHvqTPzSTkqLWQFAd1PQAbu1kTYQ93zaC3P0i59BWLlZPCPh1dcGxlNlAd5N lULH89JFlVmkR5+/hdpfHCrKabAEbeXC5UETBIiPFqSJJVXEUJGZl2lTF5udNAPsn0vH q6mtHU8qJGKqcPo95jh2E+2e49j9v5aePNvcM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=UXAyyPgeVtlunpYIMmBjubXgueedm76oEyvtTdN6kvE=; b=V0/3AhvcTk+lGSj4t2PK1A6MFP1bbExKO//JucsyQ9r8RD4O0CejBIiSePvnxT2S22 zzJD3vHOsMU8ozWY5nUTmI78hjYNR8jH9OHHdMNWuNkNIolDwGcv8LpP4waXeXZF3+4h T7b//S/LotoKFVgTf+2ET5R25AblaapkKIMd5KnCiAAHBy9C3IP5zaSfolOpcDea4sBT szdjQZI/plfRtbyAOSiQKDgb8kR7IQDdM8SYrwXzDHrSFMurLJLSFq1c6FIlWPLwn2KX nOTy0CpJPHN3bNXwANPF2r80lFgqwaf62VULucaRPvrOoiYNVg8PfDVpO0USNx0DbxH9 xsbg== X-Gm-Message-State: AODbwcDsO7InLgBK6MyW2hdwIdsw2wstYQ+ZeUDPVrXnS3bagWmlnib7 tIyLjwkhbcoQgFVY X-Received: by 10.98.192.80 with SMTP id x77mr43149160pff.1.1495690149376; Wed, 24 May 2017 22:29:09 -0700 (PDT) Received: from localhost.localdomain ([104.237.95.182]) by smtp.gmail.com with ESMTPSA id t66sm9846737pfe.134.2017.05.24.22.29.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 24 May 2017 22:29:08 -0700 (PDT) From: Alex Shi To: Peter Zijlstra , Ingo Molnar , Jonathan Corbet , linux-kernel@vger.kernel.org (open list:LOCKING PRIMITIVES), linux-doc@vger.kernel.org (open list:DOCUMENTATION) Cc: Alex Shi , Steven Rostedt , Sebastian Siewior , Mathieu Poirier , Juri Lelli , Thomas Gleixner Subject: [PATCH v2 2/3] rtmutex: update rt-mutex Date: Thu, 25 May 2017 13:26:33 +0800 Message-Id: <1495689995-29849-2-git-send-email-alex.shi@linaro.org> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1495689995-29849-1-git-send-email-alex.shi@linaro.org> References: <1495689995-29849-1-git-send-email-alex.shi@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The rtmutex remove a pending owner bit in in rt_mutex::owner, in commit 8161239a8bcc ("rtmutex: Simplify PI algorithm and make highest prio task get lock") But the document was changed accordingly. Updating it to a meaningful state. BTW, as 'Steven Rostedt' mentioned: There is still technically a "Pending Owner", it's just not called that anymore. The pending owner happens to be the top_waiter of a lock that has no owner and has been woken up to grab the lock. Signed-off-by: Alex Shi Cc: Steven Rostedt Cc: Sebastian Siewior Cc: Mathieu Poirier Cc: Juri Lelli Cc: Thomas Gleixner To: linux-doc@vger.kernel.org To: linux-kernel@vger.kernel.org To: Jonathan Corbet To: Ingo Molnar To: Peter Zijlstra --- Documentation/locking/rt-mutex.txt | 58 +++++++++++++++++--------------------- 1 file changed, 26 insertions(+), 32 deletions(-) -- 1.9.1 diff --git a/Documentation/locking/rt-mutex.txt b/Documentation/locking/rt-mutex.txt index 243393d..35793e0 100644 --- a/Documentation/locking/rt-mutex.txt +++ b/Documentation/locking/rt-mutex.txt @@ -28,14 +28,13 @@ magic bullet for poorly designed applications, but it allows well-designed applications to use userspace locks in critical parts of an high priority thread, without losing determinism. -The enqueueing of the waiters into the rtmutex waiter list is done in +The enqueueing of the waiters into the rtmutex waiter tree is done in priority order. For same priorities FIFO order is chosen. For each rtmutex, only the top priority waiter is enqueued into the owner's -priority waiters list. This list too queues in priority order. Whenever +priority waiters tree. This tree too queues in priority order. Whenever the top priority waiter of a task changes (for example it timed out or -got a signal), the priority of the owner task is readjusted. [The -priority enqueueing is handled by "plists", see include/linux/plist.h -for more details.] +got a signal), the priority of the owner task is readjusted. The +priority enqueueing is handled by "pi_waiters". RT-mutexes are optimized for fastpath operations and have no internal locking overhead when locking an uncontended mutex or unlocking a mutex @@ -46,34 +45,29 @@ is used] The state of the rt-mutex is tracked via the owner field of the rt-mutex structure: -rt_mutex->owner holds the task_struct pointer of the owner. Bit 0 and 1 -are used to keep track of the "owner is pending" and "rtmutex has -waiters" state. +lock->owner holds the task_struct pointer of the owner. Bit 0 is used to +keep track of the "lock has waiters" state. - owner bit1 bit0 - NULL 0 0 mutex is free (fast acquire possible) - NULL 0 1 invalid state - NULL 1 0 Transitional state* - NULL 1 1 invalid state - taskpointer 0 0 mutex is held (fast release possible) - taskpointer 0 1 task is pending owner - taskpointer 1 0 mutex is held and has waiters - taskpointer 1 1 task is pending owner and mutex has waiters + owner bit0 + NULL 0 lock is free (fast acquire possible) + NULL 1 lock is free and has waiters and the top waiter + is going to take the lock* + taskpointer 0 lock is held (fast release possible) + taskpointer 1 lock is held and has waiters** -Pending-ownership handling is a performance optimization: -pending-ownership is assigned to the first (highest priority) waiter of -the mutex, when the mutex is released. The thread is woken up and once -it starts executing it can acquire the mutex. Until the mutex is taken -by it (bit 0 is cleared) a competing higher priority thread can "steal" -the mutex which puts the woken up thread back on the waiters list. +The fast atomic compare exchange based acquire and release is only +possible when bit 0 of lock->owner is 0. -The pending-ownership optimization is especially important for the -uninterrupted workflow of high-prio tasks which repeatedly -takes/releases locks that have lower-prio waiters. Without this -optimization the higher-prio thread would ping-pong to the lower-prio -task [because at unlock time we always assign a new owner]. +(*) It also can be a transitional state when grabbing the lock +with ->wait_lock is held. To prevent any fast path cmpxchg to the lock, +we need to set the bit0 before looking at the lock, and the owner may be +NULL in this small time, hence this can be a transitional state. -(*) The "mutex has waiters" bit gets set to take the lock. If the lock -doesn't already have an owner, this bit is quickly cleared if there are -no waiters. So this is a transitional state to synchronize with looking -at the owner field of the mutex and the mutex owner releasing the lock. +(**) There is a small time when bit 0 is set but there are no +waiters. This can happen when grabbing the lock in the slow path. +To prevent a cmpxchg of the owner releasing the lock, we need to +set this bit before looking at the lock. + +BTW, there is still technically a "Pending Owner", it's just not called +that anymore. The pending owner happens to be the top_waiter of a lock +that has no owner and has been woken up to grab the lock.