linux2.4 to linux2.6 Kernel Dispatch (8) __linux

Figure 2: Current

4. New Run time slice performance
In 2.6, the Time_slice variable replaces the counter variable in 2.4 to represent the remaining running time slice of the process. Time_slice despite having the same meaning as counter, the behavior in the kernel has been quite different, with the following three ways to discuss the new Run-time performance:
1) Time_slice Base value
Like counter, the default time slice of a process is related to the static priority of the process (the nice value in 2.4), using the following formula:
Min_timeslice + ((max_timeslice-min_timeslice) *
(Max_prio-1-(p)->static_prio)/(max_user_prio-1))

After the value of each macro is taken, the result is as shown in the figure:

It can be seen that the core maps the 100~139 priority to the 200ms~10ms time slice, the larger the priority value, the smaller the allotted time slice.
Compared to the default time slice of the process in 2.4, when Nice is 0 o'clock, the 2.6 benchmark value is 100ms greater than 2.4 of 60ms.
The average time slice of a process
The average time slice of the core definition process Avg_timeslice to the length of the time slice with a nice value of 0, which is approximately 102ms based on the above formula. This number participates in the priority calculation as a datum value for the process run time.
2) changes in Time_slice
The Time_slice value of the process represents the remaining size of the running time slice of the process, splits the time slice with the parent process when the process is created, decrements during the run, and, once it is 0, assigns the base value again to the Static_prio value and requests the dispatch. The decrease and reset of the time slice is performed in the clock Interrupt (Sched_tick ()), in addition to the change in the Time_slice value, mainly during the creation process and the process exit:
A) process creation
Similar to 2.4, in order to prevent a process from repeatedly fork to steal a time slice, the child process is created without allocating its own time slice, but with the parent process dividing the remaining time slices of the parent process. That is, when the fork is over, the time slice is equal to the time slice of the original parent process.
(b) Process exit
When the process exits (Sched_exit ()), according to the value of the First_time_slice to determine whether they have never redistributed the time slice, if so, then return their remaining time slices to the parent process (guaranteed no more than Max_timeslice). This action causes the process to not be penalized for creating a short-term subprocess (as opposed to being rewarded for creating a child process). If the process has run out of time slices from the parent process, there is no need to return it (this is not considered in 2.4).
3) The effect of Time_slice on scheduling
In 2.4, the process-remaining time slice is the most influential factor for dynamic precedence in addition to the Nice value, and the process in which the number of dormant times is increased, and its time slices are stacked, thereby calculating a greater priority, which is the way in which the scheduler reflects the priority strategy for the interactive process. But the fact that a lot of sleep does not mean that the process is interactive, it can only mean that it is IO-intensive, therefore, this method is very low precision, and sometimes because of the misuse of frequent disk access to the database application as an interactive process, but instead caused the real user terminal response slow.
The scheduler of 2.6 divides the ready process into active, expired two classes with the time slice exhaustion as the standard, corresponding to different ready queues, the former has absolute dispatch priority relative to the latter--only when the active process time slice is exhausted, the expired process has the opportunity to run. But when picking processes in active, the scheduler no longer takes process-remaining time slices as a factor affecting scheduling priorities, and in order to meet the kernel-deprivation requirements, the non-real-time interactive processes that are too long for the timeline are divided artificially into several segments (each section is called a run granularity, defined below) run, After each run, it is stripped from the CPU and placed at the end of the corresponding active ready queue, providing the opportunity for other processes with equal priority.
This operation is performed after the Schedule_tick () is decremented to the time slice. At this point, even if the process does not run out of time, as long as the process meets the following four conditions, it will be forced from the CPU to be stripped down, to re-enter the queue to wait for the next dispatch:
The process is currently in the active ready queue;
The process is an interactive process (Task_interactive () returns True, see "more accurate interactive process first", nice greater than 12 o'clock, the macro returns to the permanent fake);
The time slice that the process has consumed (the time base value minus the remaining time slice) is exactly the integer multiple of the run granularity;
The remaining time slice is not less than the run granularity

The definition of run granularity timeslice_granularity is defined as a macro associated with the sleep_avg of the process and the total number of CPUs in the system. Since Sleep_avg actually represents the difference between the process's non running time and the running time and is closely related to the degree of interaction, the definition of the operation granularity illustrates the following two scheduling strategies for the kernel:
The higher the level of process interaction, the smaller the operation granularity, which is allowed by the operating characteristics of the interactive process, and corresponding to the cpu-bound process to avoid Cache refresh, should not be fragmented;
The more the system CPU number, the larger the operation granularity.

5.   Optimized priority computing method
in the  2.4  kernel, priority computing and selection of candidate processes are concentrated in the scheduler, unable to guarantee the scheduler's execution time, as described in the previous  runqueue  The data structure has been mentioned. The candidate processes in the 2.6  kernel are selected directly from an array of priority queues that have been sorted by algorithm, while priority calculations are dispersed across multiple places. This section is divided into two parts to describe this new priority calculation method, in part the priority calculation process, and the timing of the priority calculation (and the process team).
1)   Priority computing Process
The calculation of dynamic precedence is done primarily by the  effect_prio ()   function, which is fairly simple, where the priority of a non-real-time process is determined only by static precedence (static_ Prio) and the sleep_avg  value of the process are two factors, and the priority of the real-time process is actually set in  setscheduler ()   (see "Real-time performance of the scheduling system", which takes into account only non-real-time processes), And will not change once set. In comparison, the  goodness ()   function of,2.4  is even more complex, considering the cost of  CPU Cache  failure and the overhead of memory switching are no longer considered. The implementation of the
2.6  dynamic priority algorithm is key to the  sleep_avg  variable, and the scope of,sleep_avg  in  effective_prio ()   is  0~ MAX_SLEEP_AVG, the following formula transforms into a  bonus between-max_bonus/2~max_bonus/2 :