Lines Matching refs:process
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
30 priority process is prevented from running by a lower priority process for
35 priority process, C is the lowest, and B is in between. A tries to grab a lock
38 but by doing so, it is in fact preempting A which is a higher priority process.
63 PI is where a process inherits the priority of another process if the other
64 process blocks on a lock owned by the current process. To make this easier
79 processes to inherit priorities from a previous process that is
96 process. Since the scope of the waiter is within the code for
97 a process being blocked on the mutex, it is fine to allocate
98 the waiter on the process's stack (local variable). This
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
112 that a specific process owns.
114 Note: task and process are used interchangeably in this document, mostly to
123 would never diverge, since a process can't be blocked on more than one
144 To show where two chains merge, we could add another process F and
151 Since a process may own more than one mutex, but never be blocked on more than
166 Also since a mutex may have more than one process blocked on it, we can
167 have multiple chains merge at mutexes. If we add another process G that is
217 To keep track of the PI chains, each process has its own PI list. This is
218 a list of all top waiters of the mutexes that are owned by the process.
220 blocked on mutexes owned by the process.
227 This list is stored in the task structure of a process as a plist called
362 process must adjust its priority. With the help of the pi_list of a
363 process this is rather easy to know what needs to be adjusted.
372 task's own normal priority, or if a process of a higher priority is waiting on
392 process has just blocked on a mutex owned by the task, __rt_mutex_adjust_prio
410 The rt_mutex_adjust_prio_chain can be used either to boost or lower process
414 (de)boosting (the owner of a mutex that a process is blocking on), a flag to
416 that is the process's waiter struct that is blocked on the mutex (although this
441 A check is now done to see if the original waiter (the process that is blocked
444 there is another process higher in priority that is blocked on one of the
470 process on the mutex's wait_list, then we remove the previous top waiter
494 process as the tasked being worked on, we are OK.
525 What this means is that an owner was chosen by the process releasing the
528 Why is this important? Why can't we just give the mutex to another process
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
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
547 new process is given a mutex that it was blocked on, it is only given
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
551 process "steal" the mutex from the pending owner (only if it is still pending)
625 in try_to_take_rt_mutex if the owner field points to another process.
666 The accounting of a mutex and process is done with the waiter structure of
667 the process. The "task" field is set to the process, and the "lock" field
672 add the waiter to the wait_list. If the current process is the highest
673 priority process currently waiting on this mutex, then we remove the
674 previous top waiter process (if it exists) from the pi_list of the owner,
675 and add the current process to that list. Since the pi_list of the owner
683 Now all locks are released, and if the current process is still blocked on a
700 algorithm needs to be careful. This is because the current process is
702 especially on SCHED_OTHER tasks, the current process can be the
710 pi_list of the owner. If this process was a high priority process, then
722 waiters, the owner field of the mutex would equal the current process and