Lines Matching refs:priority

15 The goal of this document is to help others understand the priority
23 Priority inversion is when a lower priority process executes while a higher
24 priority process wants to run.  This happens for several reasons, and
25 most of the time it can't be helped.  Anytime a high priority process wants
26 to use a resource that a lower priority process has (a mutex for example),
27 the high priority process must wait until the lower priority process is done
28 with the resource.  This is a priority inversion.  What we want to prevent
29 is something called unbounded priority inversion.  That is when the high
30 priority process is prevented from running by a lower priority process for
33 The classic example of unbounded priority inversion is where you have three
35 priority process, C is the lowest, and B is in between. A tries to grab a lock
37 meantime, B executes, and since B is of a higher priority than C, it preempts C,
38 but by doing so, it is in fact preempting A which is a higher priority process.
41 never give C a chance to release the lock.  This is called unbounded priority
63 PI is where a process inherits the priority of another process if the other
67 This time, when A blocks on the lock owned by C, C would inherit the priority
69 the high priority of A.  As soon as C releases the lock, it loses its
70 inherited priority, and A then can continue with the resource that C had.
109 top waiter - The highest priority process waiting on a specific mutex.
111 top pi waiter - The highest priority process waiting on one of the mutexes
121 The PI chain is a list of processes and mutexes that may cause priority
163 also call it the Top of the chain) must be equal to or higher in priority
182 If process G has the highest priority in the chain, then all the tasks up
190 mutex has a rbtree to store these waiters by priority.  This tree is protected
203 The top of the task's PI tree is always the highest priority task that
205 inherited a priority, it will always be the priority of the task that is
340 process must adjust its priority.  With the help of the pi_waiters of a
346 rt_mutex_adjust_prio examines the priority of the task, and the highest
347 priority process that is waiting any of mutexes owned by the task. Since
348 the pi_waiters of a task holds an order by priority of all the top waiters
350 pi waiter to its own normal/deadline priority and take the higher one.
351 Then rt_mutex_setprio is called to adjust the priority of the task to the
352 new priority. Note that rt_mutex_setprio is defined in kernel/sched/core.c
353 to implement the actual change in priority.
356 	higher the priority. A "prio" of 5 is of higher priority than a
360 or decrease the priority of the task.  In the case that a higher priority
362 would increase/boost the task's priority.  But if a higher priority task
364 would decrease/unboost the priority of the task.  That is because the pi_waiters
365 always contains the highest priority task that is waiting on a mutex owned
366 by the task, so we only need to compare the priority of that top pi waiter
367 to the normal priority of the given task.
396 performed on it.  This means that the task is set to the priority that it
443    2) The current task is the highest priority against all other
448 (highest priority task waiting on the lock) is added to this task's
463 current priority.
467 highest priority process currently waiting on this mutex, then we remove the
471 should adjust its priority accordingly.
534 marked to prevent lower priority tasks from stealing the lock.