From patchwork Fri Apr 21 14:12:54 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Shi X-Patchwork-Id: 97907 Delivered-To: patch@linaro.org Received: by 10.182.246.10 with SMTP id xs10csp331044obc; Fri, 21 Apr 2017 07:14:54 -0700 (PDT) X-Received: by 10.98.138.150 with SMTP id o22mr12898389pfk.69.1492784094741; Fri, 21 Apr 2017 07:14:54 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i35si10516316plg.145.2017.04.21.07.14.54; Fri, 21 Apr 2017 07:14:54 -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 S1040603AbdDUOOq (ORCPT + 12 others); Fri, 21 Apr 2017 10:14:46 -0400 Received: from mail-yb0-f178.google.com ([209.85.213.178]:33430 "EHLO mail-yb0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1040525AbdDUONo (ORCPT ); Fri, 21 Apr 2017 10:13:44 -0400 Received: by mail-yb0-f178.google.com with SMTP id 81so43608468ybp.0 for ; Fri, 21 Apr 2017 07:13:44 -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=fCzAXwNZQysDyVkMK+nZI2vRxx+jpkkvCDK3x01O8Ys=; b=hy+pQiBlU1k5HoWC2dErJWGQBhzW0amtqxFO+zMUV2G0qS2r495cfpOhB3KIXGGn+q GUe82TSj7SXz4RXhrzOnKHwsMW4Dwq44cOhvkmaBORVqy8TvB/WY/7nnSFkDGut8RmKe 6zmZLaxP45TNmFOO/LkoyFYaEOXfKdsG6X7cs= 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=fCzAXwNZQysDyVkMK+nZI2vRxx+jpkkvCDK3x01O8Ys=; b=fztiOgurHLWXIHltET5cGd+r6sLesOjZ7wcuWsv6rUNneTzFNFGnRr8ETwsK8BTOxQ rwb70JUWhGGu+psr8o7jsxcM+g6OChKM9nPy5t8+K6IcyhliYNobZewtF3Jznr0rcFYn F96XWb1FD10C6iWptw43NpsGUcKT8mnuZ3hM7paMtijRkAcp1s3DcxWhRgGJlO8aMBj9 pjm3Rn2Kq2h6CrfWWadhaqcGz08V6HQGaXPfmX0kl6+fFiPL4kyaSc2/uA/5VcZLbJMN T0M1FohGb7e6RvKKyVtbYJq4jUgwTdyrVSnDzRL8Dyxp0ExkwVEQhL3IxRRAYI81/Qrb WYbQ== X-Gm-Message-State: AN3rC/6IhixIjE8+O5dzBo3u4jT2a29/UtAmi4t0JsXd/s8Xd3O1DN70 xujFMLzVpUpvGIAb X-Received: by 10.98.75.25 with SMTP id y25mr12874207pfa.157.1492784023695; Fri, 21 Apr 2017 07:13:43 -0700 (PDT) Received: from localhost.localdomain ([104.237.91.38]) by smtp.gmail.com with ESMTPSA id g71sm15481707pfc.41.2017.04.21.07.13.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 21 Apr 2017 07:13:42 -0700 (PDT) From: Alex Shi To: mathieu.poirier@linaro.org, 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 , Thomas Gleixner Subject: [PATCH v2 2/3] rtmutex: update rt-mutex Date: Fri, 21 Apr 2017 22:12:54 +0800 Message-Id: <1492783975-13633-2-git-send-email-alex.shi@linaro.org> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1492783975-13633-1-git-send-email-alex.shi@linaro.org> References: <1492783975-13633-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 To: linux-doc@vger.kernel.org To: linux-kernel@vger.kernel.org To: Jonathan Corbet To: Ingo Molnar To: Peter Zijlstra Cc: Thomas Gleixner --- 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.