Chapter 2: Process Management and Scheduling
checks if the normal priority is in the real-time range, that is, smaller thanRT_RT_PRIO. Notice that the
check is not related to any scheduling class, but only to the numerical value of the priority.
Assume for now that we are dealing with a regular process that is not subjected to real-time scheduling.
In this case,normal_priojust returns the static priority. The effect is then simple: All three priority values
have the same value, namely, that of the static priority!
Things are different for real-time tasks, however. Observe how the normal priority is computed:
kernel/sched.c
static inline int normal_prio(struct task_struct *p)
{
int prio;if (task_has_rt_policy(p))
prio = MAX_RT_PRIO-1 - p->rt_priority;
else
prio = __normal_prio(p);
return prio;
}The normal priority needs to be computed differently for regular tasks and real-time tasks. The compu-
tation performed in__normal_priois only valid for a regular task. Real-time tasks, instead, compute the
normal priority based on theirrt_prioritysetting. Because higher values ofrt_prioritydenote higher
real-time priorities, this runs counter to the kernel-internal representation of priorities, wherelowerval-
ues meanhigherpriorities. The proper in-kernel priority value is therefore given byMAX_RT_PRIO-1 -
p->rt_priority. Notice that this time, the detection of a real-time task is, in contrast toeffective_prio,
notbased on any priority, but on the scheduling policy set in thetask_struct.
What does__normal_prioritydo? The function is really simple; it just returns the static priority:
kernel/sched.c
static inline int __normal_prio(struct task_struct *p)
{
return p->static_prio;
}Now one can certainly wonder why an extra function is used for this purpose. There is a historical reason:
Computing the normal priority in the oldO(1) scheduler was a much trickier business. Interactive tasks
had to be detected and their priority boosted, while non-interactive tasks had to be penalized to obtain
good interactive behavior of the system. This required numerous heuristic calculations that either did
the job well — or failed at it. The new scheduler, thankfully, does not require such magical calculations
anymore.
However, one question remains: Why doesthe kernel base the real-time check ineffective_prioon the
numerical value of the priority instead of usingtask_has_rt_policy? This is required for non-real-time
tasks that have been temporarily boosted to a real-time priority, which can happen when RT-Mutexes
are in use.^26
(^26) Real-time mutexes allow for protection of dangerous parts of the kernel against concurrent access by multiple processors. However,
a phenomenon calledpriority inversion, in which a process with lower priority executes even though a process with higher priority
is waiting for the CPU, can occur. This can be solved by temporarilyboosting the priority of processes. Refer to the discussion in
Section 5.2.8 for more details about this problem.