Lines Matching full:priority

16 The goal of this document is to help others understand the priority
21 Unbounded Priority Inversion
24 Priority inversion is when a lower priority process executes while a higher
25 priority process wants to run.  This happens for several reasons, and
26 most of the time it can't be helped.  Anytime a high priority process wants
27 to use a resource that a lower priority process has (a mutex for example),
28 the high priority process must wait until the lower priority process is done
29 with the resource.  This is a priority inversion.  What we want to prevent
30 is something called unbounded priority inversion.  That is when the high
31 priority process is prevented from running by a lower priority process for
34 The classic example of unbounded priority inversion is where you have three
36 priority process, C is the lowest, and B is in between. A tries to grab a lock
38 meantime, B executes, and since B is of a higher priority than C, it preempts C,
39 but by doing so, it is in fact preempting A which is a higher priority process.
42 never give C a chance to release the lock.  This is called unbounded priority
58 Priority Inheritance (PI)
64 PI is where a process inherits the priority of another process if the other
68 This time, when A blocks on the lock owned by C, C would inherit the priority
70 the high priority of A.  As soon as C releases the lock, it loses its
71 inherited priority, and A then can continue with the resource that C had.
117          - The highest priority process waiting on a specific mutex.
120               - The highest priority process waiting on one of the mutexes
131 The PI chain is a list of processes and mutexes that may cause priority
173 also call it the Top of the chain) must be equal to or higher in priority
192 If process G has the highest priority in the chain, then all the tasks up
200 mutex has a rbtree to store these waiters by priority.  This tree is protected
213 The top of the task's PI tree is always the highest priority task that
215 inherited a priority, it will always be the priority of the task that is
346 Priority adjustments
350 process must adjust its priority.  With the help of the pi_waiters of a
356 rt_mutex_adjust_prio examines the priority of the task, and the highest
357 priority process that is waiting any of mutexes owned by the task. Since
358 the pi_waiters of a task holds an order by priority of all the top waiters
360 pi waiter to its own normal/deadline priority and take the higher one.
361 Then rt_mutex_setprio is called to adjust the priority of the task to the
362 new priority. Note that rt_mutex_setprio is defined in kernel/sched/core.c
363 to implement the actual change in priority.
367 	higher the priority. A "prio" of 5 is of higher priority than a
371 or decrease the priority of the task.  In the case that a higher priority
373 would increase/boost the task's priority.  But if a higher priority task
375 would decrease/unboost the priority of the task.  That is because the pi_waiters
376 always contains the highest priority task that is waiting on a mutex owned
377 by the task, so we only need to compare the priority of that top pi waiter
378 to the normal priority of the given task.
407 performed on it.  This means that the task is set to the priority that it
455    2) The current task is the highest priority against all other
460 (highest priority task waiting on the lock) is added to this task's
475 current priority.
479 highest priority process currently waiting on this mutex, then we remove the
483 should adjust its priority accordingly.
546 marked to prevent lower priority tasks from stealing the lock.