Re: [PATCH v2 1/3] rtmutex: update rt-mutex-design

[Alex Shi]

  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.
> 

Re: [PATCH v2 1/3] rtmutex: update rt-mutex-design

[Alex Shi]

  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.
> 

Re: [PATCH v2 1/3] rtmutex: update rt-mutex-design

[Alex Shi]

On 04/21/2017 11:47 PM, Peter Zijlstra wrote:
> On Fri, Apr 21, 2017 at 10:12:53PM +0800, Alex Shi wrote:
>> diff --git a/Documentation/locking/rt-mutex-design.txt 
>> b/Documentation/locking/rt-mutex-design.txt
>> index 8666070..11beb55 100644
>> --- a/Documentation/locking/rt-mutex-design.txt
>> +++ b/Documentation/locking/rt-mutex-design.txt
>> @@ -97,9 +97,9 @@ waiter   - A waiter is a struct that is stored on the 
>> stack of a blocked
>> a process being blocked on the mutex, it is fine to allocate
>> the waiter on the process's stack (local variable).  This
>> 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
>> +   place the task in waiters rbtree of a mutex as well as the
>> +   pi_waiters rbtree of a mutex owner task (described below).
> 
> whitespace fail

Keep using the old style. Thanks!

> 
>>  
>> waiter is sometimes used in reference to the task that is waiting
>> on a mutex. This is the same as waiter->task.
>> @@ -179,53 +179,35 @@ again.
>>   |
>> F->L5-+
>>  
>> +If the G process has highest priority in the chain, then all the tasks up
>> +the chain (A and B in this example), must have their priorities increased
>> +to that of G.
> 
> No, only the top task that's actually runnable needs to be modified. The
> rest we don't care about because they're blocked.

As my understand the task B is also changed in function 
rt_mutex_adjust_prio_chain, even it was blocked. Since it should be run and 
then release the lock L2 before task G.

> 
>> +Since the pi_waiters of a task holds an order by priority of all the top 
>> waiters
>> +of all the mutexes that the task owns, rt_mutex_getprio simply needs to 
>> compare
>> +the top pi waiter to its own normal priority, and return the higher priority
>> +back.
> 
> rt_mutex_getprio() doesn't exist.

Thanks. Fixed.

> 
>> +The main operation of this function is summarized by Thomas Gleixner in
>> +rtmutex.c. See the 'Chain walk basics and protection scope' comment for 
>> further
>> +details.
> 
> Since all the useful bits are there anyway, why keep this document
> around at all?
> 

Uh, we already removed much contents of this function. The remain part are not 
simple duplicated, and also give me much help when I try to understand the 
rtmutex. :)

Any comments for 3rd version? :)

Thanks!


>From fab767624f0da0013154c53171cdeb6cec6e74c3 Mon Sep 17 00:00:00 2001
From: Alex Shi 
Date: Tue, 18 Apr 2017 17:40:11 +0800
Subject: [PATCH v3 1/3] rtmutex: update rt-mutex-design

The rt-mutex-design documents didn't gotten meaningful update from its
first version. Even after owner's pending bit was removed in commit 8161239a8bcc
("rtmutex: Simplify PI algorithm and make highest prio task get lock")
and priority list 'plist' changed to rbtree. And Peter Zijlstra did some
clean up and fix for deadline task changes on tip tree.

So update it to latest code and make it meaningful.

Signed-off-by: Alex Shi 
Cc: Steven Rostedt 
Cc: Sebastian Siewior 
To: linux-...@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-design.txt | 418 +++---
 1 file changed, 97 insertions(+), 321 deletions(-)

diff --git a/Documentation/locking/rt-mutex-design.txt 
b/Documentation/locking/rt-mutex-design.txt
index 8666070..942cf45 100644
--- a/Documentation/locking/rt-mutex-design.txt
+++ b/Documentation/locking/rt-mutex-design.txt
@@ -97,9 +97,9 @@ waiter   - A waiter is a struct that is stored on the stack 
of a blocked
a process being blocked on the mutex, it is fine to allocate
the waiter on the process's stack (local variable).  This
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
+   place the task in waiters rbtree of a mutex as well as the
+   pi_waiters rbtree of a mutex owner task (described below).
 
waiter is sometimes used in reference to the task that is waiting
on a mutex. This is the same as waiter->task.
@@ -179,53 +179,35 @@ again.
  |

Re: [PATCH v2 1/3] rtmutex: update rt-mutex-design

[Alex Shi]

On 04/21/2017 11:47 PM, Peter Zijlstra wrote:
> On Fri, Apr 21, 2017 at 10:12:53PM +0800, Alex Shi wrote:
>> diff --git a/Documentation/locking/rt-mutex-design.txt 
>> b/Documentation/locking/rt-mutex-design.txt
>> index 8666070..11beb55 100644
>> --- a/Documentation/locking/rt-mutex-design.txt
>> +++ b/Documentation/locking/rt-mutex-design.txt
>> @@ -97,9 +97,9 @@ waiter   - A waiter is a struct that is stored on the 
>> stack of a blocked
>> a process being blocked on the mutex, it is fine to allocate
>> the waiter on the process's stack (local variable).  This
>> 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
>> +   place the task in waiters rbtree of a mutex as well as the
>> +   pi_waiters rbtree of a mutex owner task (described below).
> 
> whitespace fail

Keep using the old style. Thanks!

> 
>>  
>> waiter is sometimes used in reference to the task that is waiting
>> on a mutex. This is the same as waiter->task.
>> @@ -179,53 +179,35 @@ again.
>>   |
>> F->L5-+
>>  
>> +If the G process has highest priority in the chain, then all the tasks up
>> +the chain (A and B in this example), must have their priorities increased
>> +to that of G.
> 
> No, only the top task that's actually runnable needs to be modified. The
> rest we don't care about because they're blocked.

As my understand the task B is also changed in function 
rt_mutex_adjust_prio_chain, even it was blocked. Since it should be run and 
then release the lock L2 before task G.

> 
>> +Since the pi_waiters of a task holds an order by priority of all the top 
>> waiters
>> +of all the mutexes that the task owns, rt_mutex_getprio simply needs to 
>> compare
>> +the top pi waiter to its own normal priority, and return the higher priority
>> +back.
> 
> rt_mutex_getprio() doesn't exist.

Thanks. Fixed.

> 
>> +The main operation of this function is summarized by Thomas Gleixner in
>> +rtmutex.c. See the 'Chain walk basics and protection scope' comment for 
>> further
>> +details.
> 
> Since all the useful bits are there anyway, why keep this document
> around at all?
> 

Uh, we already removed much contents of this function. The remain part are not 
simple duplicated, and also give me much help when I try to understand the 
rtmutex. :)

Any comments for 3rd version? :)

Thanks!


>From fab767624f0da0013154c53171cdeb6cec6e74c3 Mon Sep 17 00:00:00 2001
From: Alex Shi 
Date: Tue, 18 Apr 2017 17:40:11 +0800
Subject: [PATCH v3 1/3] rtmutex: update rt-mutex-design

The rt-mutex-design documents didn't gotten meaningful update from its
first version. Even after owner's pending bit was removed in commit 8161239a8bcc
("rtmutex: Simplify PI algorithm and make highest prio task get lock")
and priority list 'plist' changed to rbtree. And Peter Zijlstra did some
clean up and fix for deadline task changes on tip tree.

So update it to latest code and make it meaningful.

Signed-off-by: Alex Shi 
Cc: Steven Rostedt 
Cc: Sebastian Siewior 
To: linux-...@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-design.txt | 418 +++---
 1 file changed, 97 insertions(+), 321 deletions(-)

diff --git a/Documentation/locking/rt-mutex-design.txt 
b/Documentation/locking/rt-mutex-design.txt
index 8666070..942cf45 100644
--- a/Documentation/locking/rt-mutex-design.txt
+++ b/Documentation/locking/rt-mutex-design.txt
@@ -97,9 +97,9 @@ waiter   - A waiter is a struct that is stored on the stack 
of a blocked
a process being blocked on the mutex, it is fine to allocate
the waiter on the process's stack (local variable).  This
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
+   place the task in waiters rbtree of a mutex as well as the
+   pi_waiters rbtree of a mutex owner task (described below).
 
waiter is sometimes used in reference to the task that is waiting
on a mutex. This is the same as waiter->task.
@@ -179,53 +179,35 @@ again.
  |
F->L5-+
 
-
-Plist
--
-
-Before I go further and talk about how the PI chain is stored through lists
-on both mutexes and processes, I'll explain the plist.  This 

Re: [PATCH v2 1/3] rtmutex: update rt-mutex-design

[Mathieu Poirier]

On 21 April 2017 at 08:12, Alex Shi  wrote:
> The rt-mutex-design documents didn't gotten meaningful update from its
> first version. Even after owner's pending bit was removed in commit 
> 8161239a8bcc
> ("rtmutex: Simplify PI algorithm and make highest prio task get lock")
> and priority list 'plist' changed to rbtree. So the documents are far
> late of real code.
>
> Update it to latest code and make it meaningful.
>
> Signed-off-by: Alex Shi 
> Cc: Steven Rostedt 
> Cc: Sebastian Siewior 
> To: linux-...@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-design.txt | 390 
> +++---
>  1 file changed, 88 insertions(+), 302 deletions(-)
>
> diff --git a/Documentation/locking/rt-mutex-design.txt 
> b/Documentation/locking/rt-mutex-design.txt
> index 8666070..11beb55 100644
> --- a/Documentation/locking/rt-mutex-design.txt
> +++ b/Documentation/locking/rt-mutex-design.txt
> @@ -97,9 +97,9 @@ waiter   - A waiter is a struct that is stored on the stack 
> of a blocked
> a process being blocked on the mutex, it is fine to allocate
> the waiter on the process's stack (local variable).  This
> 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.

> +  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" .

[1]. http://lxr.free-electrons.com/source/kernel/locking/rtmutex_common.h#L25


>
> waiter is sometimes used in reference to the task that is waiting
> on a mutex. This is the same as waiter->task.
> @@ -179,53 +179,35 @@ again.
>   |
> F->L5-+
>
> -
> -Plist
> --
> -
> -Before I go further and talk about how the PI chain is stored through lists
> -on both mutexes and processes, I'll explain the plist.  This is similar to
> -the struct list_head functionality that is already in the kernel.
> -The implementation of plist is out of scope for this document, but it is
> -very important to understand what it does.
> -
> -There are a few differences between plist and list, the most important one
> -being that plist is a priority sorted linked list.  This means that the
> -priorities of the plist are sorted, such that it takes O(1) to retrieve the
> -highest priority item in the list.  Obviously this is useful to store 
> processes
> -based on their priorities.
> -
> -Another difference, which is important for implementation, is that, unlike
> -list, the head of the list is a different element than the nodes of a list.
> -So the head of the list is declared as struct plist_head and nodes that will
> -be added to the list are declared as struct plist_node.
> -
> +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, ...

> +the chain (A and B in this example), must have their priorities increased
> +to that of G.
>
>  Mutex Waiter List
>  -
>
>  Every mutex keeps track of all the waiters that are blocked on itself. The 
> mutex
> -has a plist to store these waiters by priority.  This list is protected by
> +has a rbtree to store these waiters by priority.  This tree is protected by
>  a spin lock that is located in the struct of the mutex. This lock is called
> -wait_lock.  Since the modification of the waiter list is never done in
> +wait_lock.  Since the modification of the waiter tree is never done in
>  interrupt context, the wait_lock can be taken without disabling interrupts.
>
>
> -Task PI List
> +Task PI Tree
>  
>
> -To keep track of the PI chains, each process has its own PI list.  This is
> -a list of all top waiters of the mutexes that are owned by the process.
> -Note that this list only holds the top waiters and not all waiters that are
> +To keep track of the PI chains, each process has its own PI rbtree.  This is
> +a tree of all top waiters of the mutexes that are owned by the process.
> +Note that this tree only holds the top waiters and not all waiters that are
>  blocked on mutexes owned by the process.
>
> -The top of the task's PI list is always the highest priority task that
> +The top of 

Re: [PATCH v2 1/3] rtmutex: update rt-mutex-design

[Mathieu Poirier]

On 21 April 2017 at 08:12, Alex Shi  wrote:
> The rt-mutex-design documents didn't gotten meaningful update from its
> first version. Even after owner's pending bit was removed in commit 
> 8161239a8bcc
> ("rtmutex: Simplify PI algorithm and make highest prio task get lock")
> and priority list 'plist' changed to rbtree. So the documents are far
> late of real code.
>
> Update it to latest code and make it meaningful.
>
> Signed-off-by: Alex Shi 
> Cc: Steven Rostedt 
> Cc: Sebastian Siewior 
> To: linux-...@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-design.txt | 390 
> +++---
>  1 file changed, 88 insertions(+), 302 deletions(-)
>
> diff --git a/Documentation/locking/rt-mutex-design.txt 
> b/Documentation/locking/rt-mutex-design.txt
> index 8666070..11beb55 100644
> --- a/Documentation/locking/rt-mutex-design.txt
> +++ b/Documentation/locking/rt-mutex-design.txt
> @@ -97,9 +97,9 @@ waiter   - A waiter is a struct that is stored on the stack 
> of a blocked
> a process being blocked on the mutex, it is fine to allocate
> the waiter on the process's stack (local variable).  This
> 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.

> +  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" .

[1]. http://lxr.free-electrons.com/source/kernel/locking/rtmutex_common.h#L25


>
> waiter is sometimes used in reference to the task that is waiting
> on a mutex. This is the same as waiter->task.
> @@ -179,53 +179,35 @@ again.
>   |
> F->L5-+
>
> -
> -Plist
> --
> -
> -Before I go further and talk about how the PI chain is stored through lists
> -on both mutexes and processes, I'll explain the plist.  This is similar to
> -the struct list_head functionality that is already in the kernel.
> -The implementation of plist is out of scope for this document, but it is
> -very important to understand what it does.
> -
> -There are a few differences between plist and list, the most important one
> -being that plist is a priority sorted linked list.  This means that the
> -priorities of the plist are sorted, such that it takes O(1) to retrieve the
> -highest priority item in the list.  Obviously this is useful to store 
> processes
> -based on their priorities.
> -
> -Another difference, which is important for implementation, is that, unlike
> -list, the head of the list is a different element than the nodes of a list.
> -So the head of the list is declared as struct plist_head and nodes that will
> -be added to the list are declared as struct plist_node.
> -
> +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, ...

> +the chain (A and B in this example), must have their priorities increased
> +to that of G.
>
>  Mutex Waiter List
>  -
>
>  Every mutex keeps track of all the waiters that are blocked on itself. The 
> mutex
> -has a plist to store these waiters by priority.  This list is protected by
> +has a rbtree to store these waiters by priority.  This tree is protected by
>  a spin lock that is located in the struct of the mutex. This lock is called
> -wait_lock.  Since the modification of the waiter list is never done in
> +wait_lock.  Since the modification of the waiter tree is never done in
>  interrupt context, the wait_lock can be taken without disabling interrupts.
>
>
> -Task PI List
> +Task PI Tree
>  
>
> -To keep track of the PI chains, each process has its own PI list.  This is
> -a list of all top waiters of the mutexes that are owned by the process.
> -Note that this list only holds the top waiters and not all waiters that are
> +To keep track of the PI chains, each process has its own PI rbtree.  This is
> +a tree of all top waiters of the mutexes that are owned by the process.
> +Note that this tree only holds the top waiters and not all waiters that are
>  blocked on mutexes owned by the process.
>
> -The top of the task's PI list is always the highest priority task that
> +The top of the task's PI tree is always the highest priority task that
>  is waiting on a mutex that is owned by the task.  So if the task has
>  inherited a priority, it 

Re: [PATCH v2 1/3] rtmutex: update rt-mutex-design

[Peter Zijlstra]

On Fri, Apr 21, 2017 at 10:12:53PM +0800, Alex Shi wrote:
> diff --git a/Documentation/locking/rt-mutex-design.txt 
> b/Documentation/locking/rt-mutex-design.txt
> index 8666070..11beb55 100644
> --- a/Documentation/locking/rt-mutex-design.txt
> +++ b/Documentation/locking/rt-mutex-design.txt
> @@ -97,9 +97,9 @@ waiter   - A waiter is a struct that is stored on the stack 
> of a blocked
> a process being blocked on the mutex, it is fine to allocate
> the waiter on the process's stack (local variable).  This
> 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
> +place the task in waiters rbtree of a mutex as well as the
> +pi_waiters rbtree of a mutex owner task (described below).

whitespace fail

>  
> waiter is sometimes used in reference to the task that is waiting
> on a mutex. This is the same as waiter->task.
> @@ -179,53 +179,35 @@ again.
>   |
> F->L5-+
>  
> +If the G process has highest priority in the chain, then all the tasks up
> +the chain (A and B in this example), must have their priorities increased
> +to that of G.

No, only the top task that's actually runnable needs to be modified. The
rest we don't care about because they're blocked.

> +Since the pi_waiters of a task holds an order by priority of all the top 
> waiters
> +of all the mutexes that the task owns, rt_mutex_getprio simply needs to 
> compare
> +the top pi waiter to its own normal priority, and return the higher priority
> +back.

rt_mutex_getprio() doesn't exist.

> +The main operation of this function is summarized by Thomas Gleixner in
> +rtmutex.c. See the 'Chain walk basics and protection scope' comment for 
> further
> +details.

Since all the useful bits are there anyway, why keep this document
around at all?

Re: [PATCH v2 1/3] rtmutex: update rt-mutex-design

[Peter Zijlstra]

On Fri, Apr 21, 2017 at 10:12:53PM +0800, Alex Shi wrote:
> diff --git a/Documentation/locking/rt-mutex-design.txt 
> b/Documentation/locking/rt-mutex-design.txt
> index 8666070..11beb55 100644
> --- a/Documentation/locking/rt-mutex-design.txt
> +++ b/Documentation/locking/rt-mutex-design.txt
> @@ -97,9 +97,9 @@ waiter   - A waiter is a struct that is stored on the stack 
> of a blocked
> a process being blocked on the mutex, it is fine to allocate
> the waiter on the process's stack (local variable).  This
> 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
> +place the task in waiters rbtree of a mutex as well as the
> +pi_waiters rbtree of a mutex owner task (described below).

whitespace fail

>  
> waiter is sometimes used in reference to the task that is waiting
> on a mutex. This is the same as waiter->task.
> @@ -179,53 +179,35 @@ again.
>   |
> F->L5-+
>  
> +If the G process has highest priority in the chain, then all the tasks up
> +the chain (A and B in this example), must have their priorities increased
> +to that of G.

No, only the top task that's actually runnable needs to be modified. The
rest we don't care about because they're blocked.

> +Since the pi_waiters of a task holds an order by priority of all the top 
> waiters
> +of all the mutexes that the task owns, rt_mutex_getprio simply needs to 
> compare
> +the top pi waiter to its own normal priority, and return the higher priority
> +back.

rt_mutex_getprio() doesn't exist.

> +The main operation of this function is summarized by Thomas Gleixner in
> +rtmutex.c. See the 'Chain walk basics and protection scope' comment for 
> further
> +details.

Since all the useful bits are there anyway, why keep this document
around at all?