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
193 being that plist is a priority sorted linked list. This means that the
195 highest priority item in the list. Obviously this is useful to store processes
208 has a plist to store these waiters by priority. This list is protected by
222 The top of the task's PI list is always the highest priority task that
224 inherited a priority, it will always be the priority of the task that is
362 process must adjust its priority. With the help of the pi_list of a
371 rt_mutex_getprio returns the priority that the task should have. Either the
372 task's own normal priority, or if a process of a higher priority is waiting on
373 a mutex owned by the task, then that higher priority should be returned.
374 Since the pi_list of a task holds an order by priority list of all the top
376 to compare the top pi waiter to its own normal priority, and return the higher
377 priority back.
381 is an inverse order of the actual priority. So a "prio" of 5 is
382 of higher priority than a "prio" of 10.)
385 result does not equal the task's current priority, then rt_mutex_setprio
386 is called to adjust the priority of the task to the new priority.
388 actual change in priority.
391 or decrease the priority of the task. In the case that a higher priority
393 would increase/boost the task's priority. But if a higher priority task
395 would decrease/unboost the priority of the task. That is because the pi_list
396 always contains the highest priority task that is waiting on a mutex owned
397 by the task, so we only need to compare the priority of that top pi waiter
398 to the normal priority of the given task.
426 performed on it. This means that the task is set to the priority that it
444 there is another process higher in priority that is blocked on one of the
447 we don't need to do any more changes to the priority of the current task, or any
448 task that owns a mutex that this current task is waiting on. A priority chain
451 The next check sees if the task's waiter plist node has the priority equal to
452 the priority the task is set at. If they are equal, then we are done with
453 the loop. Remember that the function started with the priority of the
469 task's entry in the owner's pi_list. If the task is the highest priority
479 did the priority updates, that means we are deboosting/lowering the
532 priority process run as long as possible with little latencies and delays.
533 If a high priority process owns a mutex that a lower priority process is
534 blocked on, when the mutex is released it would be given to the lower priority
535 process. What if the higher priority process wants to take that mutex again.
536 The high priority process would fail to take that mutex that it just gave up
537 and it would need to boost the lower priority process to run with full
538 latency of that critical section (since the low priority process just entered
541 There's no reason a high priority process that gives up a mutex should be
543 mutex has not woken up yet, there's no reason that the higher priority process
549 priority process comes in and tries to grab that mutex. If a higher priority
550 process does come along and wants that mutex, we let the higher priority
610 If the pending owner is not current, we check to see if the current priority is
640 priority than the current task.
669 priority.
673 priority process currently waiting on this mutex, then we remove the
677 should adjust its priority accordingly.
703 highest priority task on the wait_list.
710 pi_list of the owner. If this process was a high priority process, then