From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1171732AbdDXNpk (ORCPT ); Mon, 24 Apr 2017 09:45:40 -0400 Received: from mail-pg0-f43.google.com ([74.125.83.43]:34500 "EHLO mail-pg0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1171714AbdDXNp2 (ORCPT ); Mon, 24 Apr 2017 09:45:28 -0400 Subject: Re: [PATCH v2 1/3] rtmutex: update rt-mutex-design To: Mathieu Poirier References: <1492783975-13633-1-git-send-email-alex.shi@linaro.org> Cc: Peter Zijlstra , Ingo Molnar , Jonathan Corbet , "open list:LOCKING PRIMITIVES" , "open list:DOCUMENTATION" , Steven Rostedt , Sebastian Siewior , Thomas Gleixner From: Alex Shi Message-ID: <2c89542e-befa-6e0b-60b0-b700086d83c1@linaro.org> Date: Mon, 24 Apr 2017 21:45:20 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org structure holds a pointer to the task, as well as the mutex that >> - the task is blocked on. It also has the plist node structures to >> - place the task in the waiter_list of a mutex as well as the >> - pi_list of a mutex owner task (described below). >> + the task is blocked on. It also has a rbtree node structures to > > Here I assume we are talking about struct rt_mutex_waiter[1]. If so I > suggest to replace rbtree with rb_node. They are the same thing here, rbtree node and rb_node. :) > >> + place the task in waiters rbtree of a mutex as well as the >> + pi_waiters rbtree of a mutex owner task (described below). > > Also following the comment for @pi_tree_entry, s/"a mutex owner > task"/"a mutex owner waiters tree" . As my understand, pi_waiters is in task structure. We refer to what's the pi_tree_entry in. > > [1]. http://lxr.free-electrons.com/source/kernel/locking/rtmutex_common.h#L25 > > >> - >> +If the G process has highest priority in the chain, then all the tasks up > > If process G has the highest priority in the chain, ... Sounds better. Thanks! >> +mutex (waiter "task" field is not NULL), then we go to sleep (call schedule) >> + > > This change was likely not done on purpose. Yes. Thanks. >