From patchwork Fri Jul 7 02:52:01 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Shi X-Patchwork-Id: 107185 Delivered-To: patch@linaro.org Received: by 10.140.101.44 with SMTP id t41csp2872127qge; Thu, 6 Jul 2017 19:53:49 -0700 (PDT) X-Received: by 10.98.211.89 with SMTP id q86mr28999490pfg.37.1499396029387; Thu, 06 Jul 2017 19:53:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1499396029; cv=none; d=google.com; s=arc-20160816; b=v7jhA2VjYlSKTwtcY4JzzvAXoUDwM0WO0g1rfe5Mo5KdDrI1ReJkkx13gNRLhxCsKa 5I+u4W9bJEEdYJj3C3o2UPWexV53pIK7OlUz3SK3OFXx09lGDWZ0sMR4BXm2kRNjW+67 CZ4n9z+FqWN9M3ktJUk+v/Mxq/qMp7gRi0v+aoqVzhk9yy3H7u7WDUGj9oByr2uzWnX7 y0q+jx0vfcxqLS+9s7ajhJkOWiWWt1e/WoZZbTZWEKrFxnP47iUkbQYl2qkTXkxylukV rsUteuRV2anlzKHOVMHsotRPuBBom2I6acMm2p5DV46VjubhpgMwtQrp4pomR5YyX/sN yCtA== 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=2vqTWHPK6qe9OxcWAMADE3un6jM2o1EiFAkm988I2oo=; b=lqcu706vOnPhvdPgtJMznXzgBTx1P7IR5+y79+x7dnKOcb3RqtwN7mhmKA6tWYLK1K EE3Ez2dlUfIdaSbiha2Y8VTp3bkQdY8pIrmBXp+4vVHMK+5qoiJ+A1JyBlldvVlxobxd MtH5e6y9ZAbVV3Z8N9cards7haE7kjmY59QGoGGxQaoxFKOXGX8+gZ+fDV7nSy2/THUm dwjPqsTL7U76N1brSXxxgDsoaL7Q9EcCga3FdpdPkqzV9QryL2XKyCcZsCdz/YJGHgvf p5mhedVlHwQAxrEz2l4jysNr0yHxfTIspUeDEPEllvZ+C0NK96YCI5RUNbuRCPGMu9eA hLJw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.b=T8MM7kFU; 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 l190si1186888pfc.459.2017.07.06.19.53.49; Thu, 06 Jul 2017 19:53:49 -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 header.b=T8MM7kFU; 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 S1753359AbdGGCx1 (ORCPT + 25 others); Thu, 6 Jul 2017 22:53:27 -0400 Received: from mail-pg0-f52.google.com ([74.125.83.52]:34217 "EHLO mail-pg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753296AbdGGCxZ (ORCPT ); Thu, 6 Jul 2017 22:53:25 -0400 Received: by mail-pg0-f52.google.com with SMTP id t186so10088344pgb.1 for ; Thu, 06 Jul 2017 19:53:25 -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=2vqTWHPK6qe9OxcWAMADE3un6jM2o1EiFAkm988I2oo=; b=T8MM7kFU779jDMejbOQVltukGvboQ5xwI/iU2uOJtnMoG/WVXh3oQXvy4t5mh7FWpa am11ch+b7SQR/sw2PFVSbAWMBTJdnBusGLMmUCENVM4w9JscTJQIkbIx5msGljMmCmur FaVC0JYHmmrnDd1vaxALisKz37Pl2eC8EXTsI= 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=2vqTWHPK6qe9OxcWAMADE3un6jM2o1EiFAkm988I2oo=; b=EqFg9Nmy+uiuWItHN754IwB1c5r6aQj8FxLzLaNpsgUrtWu2ovcQ3u5eQ0SVk77ylE czZi4RLGNUh/09PFv4fS2M/4bHpPjGv42zckdrVEOcDByK2GMCv7HMCShBj7Y0sB+nKu wQcSYsb5FX4NsomsCuYPfghM2o3FrWvxjYIHMCuhgy+162tkRtG4JOjccwW9sRAWcISN OYsatQYlJ+voXeNp8lpskGPDCQm0Dm6Ma8sPj0/m7O69GiAimIRdAvXINkLrRZ54AsPP ainDg6Bqe/U15qgoQHYZXVUEkRYY0gOAt28XbB47+nPoKpeVUdSl/cc0wPt/0zEbwnZd 9d8w== X-Gm-Message-State: AIVw110XIqQQsWPJa+mU+wGXi3GwgW+neiak+Fax/hce0woocEHQwQEv cMdMop644Ht7QYxn X-Received: by 10.98.150.135 with SMTP id s7mr28984013pfk.172.1499396004881; Thu, 06 Jul 2017 19:53:24 -0700 (PDT) Received: from localhost.localdomain ([104.237.91.194]) by smtp.gmail.com with ESMTPSA id b28sm3579465pfm.9.2017.07.06.19.53.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 06 Jul 2017 19:53:23 -0700 (PDT) From: Alex Shi To: peterz@infradead.org, mingo@redhat.com, corbet@lwn.net, linux-kernel@vger.kernel.org (open list:LOCKING PRIMITIVES), linux-doc@vger.kernel.org (open list:DOCUMENTATION) Cc: linux-kernel@vger.kernel.org, Alex Shi , Steven Rostedt , Sebastian Siewior , Mathieu Poirier , Juri Lelli , Thomas Gleixner Subject: [PATCH v2 2/3] rtmutex: update rt-mutex Date: Fri, 7 Jul 2017 10:52:01 +0800 Message-Id: <1499395922-542-2-git-send-email-alex.shi@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1499395922-542-1-git-send-email-alex.shi@linaro.org> References: <1499395922-542-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(-) -- 2.7.4 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.