linux2.4 to linux2.6 Kernel dispatch (9) __linux

(Ns_to_jiffies ((P)->sleep_avg) * max_bonus/max_sleep_avg)-MAX_BONUS/2
As shown in the following illustration:

And then use this bonus to reduce the static priority to get the dynamic priority of the process (and limit between Max_rt_prio and Max_prio), the smaller the bonus, the higher the dynamic priority value, the lower the priority. In other words, the larger the Sleep_avg, the higher the priority.
Max_bonus is defined as max_user_prio*prio_bonus_ratio/100, that is, Sleep_avg's impact on dynamic precedence is only within the 1/4 interval (±5) of the user priority area (100~140) of the static priority, relative , the static priority, that is, the user-specified nice value is much larger than the priority calculation. This is also a large change in the 2.6 scheduling system, the scheduler tends to more by the user to design the implementation of the process priority.
The sleep_avg reflects the two strategies of the scheduling system: interactive process prioritization and equitable sharing of time-sharing systems, which we will also specialize in the next section.
2 Priority Calculation time
Priority computing is no longer focused on the scheduler's choice of candidate processes, and as long as the status of the process changes, it is possible for the core to compute and set the dynamic priority of the process:
A) Create a process
In Wake_up_forked_process (), the child processes inherit the dynamic precedence of the parent process and are added to the ready queue in which the parent process resides.
If the parent process is not in any ready queue (for example, it is a IDLE process), the priority of the child process is computed by the Effect_prio () function, and the child process is placed in the appropriate ready queue based on the result of the calculation.
(b) Wake up hibernation process
The core call Recalc_task_prio () sets the dynamic priority of the process that wakes up from hibernation, and then places it in the appropriate ready queue according to priority.
c) Dispatch to a process that is awakened from the task_interruptible state
In fact, the scheduler has already selected the candidate process at this time, but considering that the type of process is likely to be an interactive process, the Recalc_task_prio () is still invoked to revise the priority of the process (see "Process average wait Time sleep_avg"). The result of the correction will be reflected in the next dispatch.
d The process is stripped of CPU due to time slice related causes
In Schedule_tick () (started by the clock interrupt), the process may be stripped of the CPU for two reasons, one is the time slice is depleted, and the other is segmented because the time slice is too long. Both situations invoke Effect_prio () to recalculate the priority and re-enter the team.
(e) Other opportunities
These other opportunities include IDLE process initialization (Init_idle ()), Load Balancing (Move_task_away (), as described in "Scheduler-related load Balancing"), and modifying nice values (Set_user_nice ()), Modify the scheduling policy (Setscheduler ()) and other proactive requirements to change the priority level.
It is visible from the above that the calculation of dynamic priority in 2.6 occurs during the course of each process, avoiding the problem that the computation process takes too long to predict the response time of the process in a similar way in the 2.4 system. At the same time, the factors that affect the dynamic priority are reflected on the SLEEP_AVG variable.

6. Process average Wait time sleep_avg
The SLEEP_AVG value of process is the key to determine process dynamic priority and the key of process interaction evaluation, its design is the most complicated one in 2.6 dispatching system, so it can be said that the performance improvement of 2.6 dispatching system is due to the design of SLEEP_AVG. In this section, we will focus specifically on the changes in Sleep_avg and its impact on scheduling.
There are four main areas of the kernel that modify Sleep_avg: When the hibernation process is awakened (Activate_task () calls the Recalc_task_prio () function), task_interruptible The process of the state is first dispatched to (schedule () to call Recalc_task_prio ()), the process is stripped from the CPU (schedule () function), process creation, and process exit, where Recalc_task_prio () Is the most complex, which resets the priority by calculating the process's wait time (either in hibernation or waiting in the ready queue).
1 when the hibernation process is awakened
At this point, Activate_task () calls Recalc_task_prio () at the wake-up time as a parameter to calculate the effect of the time of the hibernation wait on the priority.
In Recalc_task_prio (), Sleep_avg may have four assignments, which are ultimately limited to NS_MAX_SLEEP_AVG:
A) unchanged
Awakened from Task_uninterruptible State (activated==-1), not highly interactive (! High_credit (p)), if its sleep_avg has not been less than Interactive_sleep (p), its sleep_avg will not change because of this wait.
b) Interactive_sleep (p)
Awakened from Task_uninterruptible State (activated==-1), not highly interactive (! High_credit (p)) of the user process (P->mm!=null), if its sleep_avg does not reach Interactive_sleep (p), but if added to this dormant time Sleep_time is reached, then its sleep _avg is equal to Interactive_sleep (p).
c) Max_sleep_avg-avg_timeslice
User process (P->mm!=null), if not awakened from task_uninterruptible hibernation (p->activated!=-1), and the time of this wait (Sleep_time) has exceeded Interactive_sleep (p), then its sleep_avg is placed Jiffies_to_ns (Max_sleep_avg-avg_timeslice).
D) sleep_avg+sleep_time
If all the above conditions are not met, the sleep_time is superimposed on the sleep_avg. At this point, sleep_time to undergo two revisions:
I. According to the value of Sleep_avg, the larger the sleep_avg, the smaller the corrected sleep_time:
Sleep_time =
Sleep_time * Max_bonus * (1-ns_to_jiffies (SLEEP_AVG)/max_sleep_avg)

Ii. if the level of process interaction is very low (Low_credit () returns True, see "more precise interactive process priority"), the Sleep_time is limited within the base time slice of the process as a priority penalty for the cpu-bound process.
In general, the longer the wait time, the sleep_avg should be larger, but the core excludes two situations:

The process of waking from the task_uninterruptible state, especially those with longer dormant periods, is likely to be dormant for some resource, and they should not be rewarded for the priority of waiting time, and its sleep_avg is limited to Interactive_sleep (p) within the scope (or not more than too many) (Interactive_sleep (p) meaning is seen), which is invalid for processes that have been identified as interactive.
It is not the process of waking from the task_uniterruptible state, and if this wait is too long, it should not be rewarded for the priority of the waiting time.

The relationship between Interactive_sleep (p) and nice
Ns_to_jiffies (Interactive_sleep (p)) =
Task_nice (P) *max_sleep_avg/40+
(INTERACTIVE_DELTA+1+MAX_BONUS/2) *max_sleep_avg/max_bonus-1

This macro is in direct proportion to the process nice value, stating that the lower the priority process, the longer it is allowed to be in the interactive hibernation state.

2 when the process of task_interruptible state is awakened for the first time after being dispatched
After the scheduler picks out the candidate process, if it discovers that it was first dispatched to (activated>0) after waking from task_interruptible hibernation, the scheduler will invoke Recalc_task_prio () based on the length of time it waits on the Ready queue () Readjust the sleep_avg of the process.
The Recalc_task_prio () adjustment process is exactly the same as when the hibernate process is awakened, and the difference is that at this time the wait time sleep_time participate in the calculation not of the hibernate time of the process, but of the process waiting for scheduling on the ready queue. Also, if the process is not interrupted (activated==1), Sleep_time will be constrained (delta=delta*on_runqueue_weight/100) because the process is not likely to be an interactive process at this time. From the above analysis of Recalc_task_prio (), the reduction of sleep_time generally means that the priority will decrease correspondingly, so this reward shows that the scheduler is further reducing the response time of the process, especially the interactive process.
3 The process of being switched down
As mentioned earlier, the SLEEP_AVG is the "average" wait time for the process, Recalc_task_prio () calculates the wait time, in schedule (), the sleep_avg of the process being switched down needs to subtract the time of the process from this run Run_ Time (and ensure that the result is not less than 0), this is the "average" of the embodiment: The longer the waiting, the greater the sleep_avg, the more easily the process is scheduled to run, and the longer the SLEEP_AVG, the smaller the process, the less easily scheduled.
Run_time can be represented by the difference between the system's current time and the process timestamp (the time of the last scheduled run), but not over Ns_max_sleep_avg. For an interactive process (Hight_credit (p) is true, see "more precise interactive process precedence"), Run_time also adjusts according to the value of Sleep_avg:
Run_time = run_time/(SLEEP_AVG*MAX_BONUS/MAX_SLEEP_AVG)

The result of this adjustment is that the greater the  run_time  of the interactive process is than the actual run time,sleep_avg , the more  run_time  decreases, so the process that is switched off is the last computed The bigger the  sleep_avg , the bigger the dynamic priority. The interactive process can be used to get more chance of being executed.
4)  fork 
in  wake_up_forked_process ()  , the  sleep_avg  of the parent process is multiplied by the  parent_ Penalty/100, and the  sleep_avg  of the subprocess is multiplied by  child_penalty/100. In fact, parent_penalty  is  100,CHILD_PENALTY  equals  95, which means the  sleep_avg  of the parent process does not change, The  sleep_avg  that the child inherits from the parent process reduces  5%, so the child process has a slightly lower priority than the parent process (but the child process is still placed on the same ready queue as the parent process, before the parent process-that is, "Preface"). Child processes run before the parent process ").
5)   process exits