All scheduling decisions happen in kernel mode: when a process is running in user mode, its next scheduling point won’t happen before the kernel takes control again.
Process priorities come into play in a variety of ways when scheduling, but there is one explicit path where higher priority processes can influence scheduling. When a task becomes runnable, the check_preempt_curr
hook is called, and if the newly-runnable task has a higher priority than the currently-running task, the hook requests a reschedule. This doesn’t immediately cause a reschedule, but it marks that the next time a reschedule is possible, it should be considered. This will typically happen on exit to userspace (see for example exit_to_usermode_loop
on x86), so not long after. The reschedule might also not reschedule the newly-runnable task, if another task is more “deserving” of running when the scheduler runs.
Preemption can happen whenever a preemption point is reached, or on low-latency kernels, whenever the kernel is running code that’s not in a critical section.
See the various preemption configuration options, the __schedule
function’s documentation, and the completely fair scheduler’s documentation for details.