On Fri, 14 Apr 2017 16:52:11 +0800 Alex Shi <alex.shi@xxxxxxxxxx> wrote: > >> -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, any right lock owners > > > > "any right lock owners" doesn't make sense. You mean owners to the > > right side of the tree of G? > > Yes, how about this? > +If the G process has highest priority in the chain, any rightside lock owners > +in the tree branch need to increase its' priority as high as G. If task G is the highest priority task 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. > > > > >> +need to increase its' priority as high as G. > >> [..] > > > >> + > >> > >> Waking up in the loop > >> --------------------- > >> > >> -The schedule can then wake up for a few reasons. > >> - 1) we were given pending ownership of the mutex. > >> - 2) we received a signal and was TASK_INTERRUPTIBLE > >> - 3) we had a timeout and was TASK_INTERRUPTIBLE > >> - > >> -In any of these cases, we continue the loop and once again try to grab the > >> -ownership of the mutex. If we succeed, we exit the loop, otherwise we continue > >> -and on signal and timeout, will exit the loop, or if we had the mutex stolen > >> -we just simply add ourselves back on the lists and go back to sleep. > >> +The schedule can then wake up for a few reasons, included: > > > > s/few/couple of/ > > > > s/, included// > > Thanks! > > I rewrite this section as following, any comments? :) > > Waking up in the loop > --------------------- > > The schedule can then wake up for a couple of reasons: The task can then wake up for a couple of reasons: > 1) The previous lock owner released the lock, and we are top_waiter now and the task is now the top_waiter > 2) we received a signal or timeout > > For the first reason, we could get the lock in acquisition retry and back to > TASK_RUNNING state. Actually that's not quite true. In the first case, the task will try again to acquire the lock. If it does, then it will take itself off the waiters tree and set itself back to the TASK_RUNNING state. If the lock was acquired by another task before this task could get the lock, then it will go back to sleep and wait to be woken again. > For the second reason, if task is in TASK_INTERRUPTIBLE > state, we will give up the lock acquisition, and also back to TASK_RUNNING. The second case is only applicable for tasks that are grabbing a mutex that can wake up before getting the lock, either due to a signal or a timeout (i.e. rt_mutex_timed_futex_lock()). When woken, it will try to take the lock again, if it succeeds, then the task will return with the lock held, otherwise it will return with -EINTR if the task was woken by a signal, or -ETIMEDOUT if it timed out. > Otherwise we will yield cpu and back to sleep. Nuke the above sentence. > > > > > >> + 1) we received a signal and was TASK_INTERRUPTIBLE > >> + 2) we had a timeout and was TASK_INTERRUPTIBLE > > > > >> This document was originally written for 2.6.17-rc3-mm1 > >> +was updated on 4.11-rc4. > >> diff --git a/Documentation/locking/rt-mutex.txt b/Documentation/locking/rt-mutex.txt > >> index 243393d..1481f97 100644 > > > > I'm not looking at the other document right now. > > May it's better to split this document to another patch. Yes please. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
