linux2.4 to linux2.6 kernel Dispatch (Ten) __linux

When a process finishes running, if its interaction is lower than the parent process (sleep_avg  smaller), the core adjusts  sleep_avg  of its parent process in  sched_exit ()  . The adjustment formula is as follows (with  child_sleep_avg  representing the  sleep_avg of the child process):
sleep_avg = sleep_avg*exit_weight/( exit_weight+1)  + child_sleep_avg/(exit_weight+1)
where  EXIT_WEIGHT  equals  3, so the   of the parent process sleep_avg  will reduce the  1/4 of its own  sleep_avg , and then compensate for the  1/4 of the sub process  sleep_avg , and the priority will decrease as well. The greater the degree of interaction between the child processes and the parent process, the more obvious the priority penalty is. By using process average waiting time to measure priority of process, the ratio of waiting time and running time of all processes of the same static priority at macro level tends to be consistent, which reflects the fairness of  Linux  requirements for sharing  cpu . On the other hand,sleep_avg  is also a measure of the degree of interactive process.
7.   More precise interactive process precedence
The actual effect of the interactive process priority policy is widely criticized in the  2.4  kernel, which has been greatly improved in the  2.6  kernel and, in general, The kernel has a high priority for the interactive process:
1)  sleep_avg
The impact of  sleep_avg  on process priorities has been detailed above, and it can be seen that the interactive process because of the number of sleep times and the length of their  sleep_avg  will also appropriately

Larger, so the calculated priority will be higher.
2) Interactive_credit
The system introduces a Interactive_credit process attribute (see "Improved task_struct") to characterize whether the process is an interactive process: as long as

Interactive_credit exceeds the Credit_limit threshold (High_credit () returns True), the process is considered an interactive process.
The initial value of the Interactive_credit is 0, and in both cases it will add 1, both of which are in the Recalc_task_prio () function:
User process (P->mm!=null), if not awakened from task_uninterruptible hibernation (p->activated!=-1), and the time to wait (included in hibernation)

Wait and wait in the ready queue, exceeding a certain limit (Sleep_time>interactive_sleep (p));
In addition to the above, sleep_avg after sleep_time adjustment, if greater than ns_max_sleep_avg.
In either case, once the interactive_credit exceeds (greater than) the credit_limit, it no longer increases, so the Interactive_credit maximum value is

Credit_limit+1.
The decline of interactive_credit occurs in the schedule () function. When the dispatcher runs the time to fix the sleep_avg of the process being switched down, if the sleep_avg is small

is equal to 0 and interactive_credit between-credit_limit and Credit_limit ( -100<=interactive_credit<=100), then Interactive_credit

Minus 1. The visible interactive_credit minimum is-101, and once it reaches the credit_limit+1 maximum it is not reduced again-it will remain in credit_limit+1

The high value.
That is, a process can be listed as an interactive process only if it sleeps more than once and sleeps long enough (longer than it is running, longer than the "interactive Sleep" time);

is considered an interactive process, it is always treated as an interactive process.
The interactive process using the High_credit () standard assertion is rewarded primarily for priority calculations in the following two places:
When the process is scheduled from the CPU, if it is an interactive process, it will participate in the priority calculation of the running time is less than the actual running time, so as to obtain a higher priority

(see "Process average waiting time sleep_avg");
The sleep time of the interactive process in the task_uninterruptible state is also superimposed on the sleep_avg to obtain a priority reward (see process average wait time

Sleep_avg ");
3) task_interactive ()
The core has an interactive process priority mechanism that does not use the cumulative approach of High_credit (), where the task_interactive () macro (Boolean) is used:

Prio <= Static_prio-delta (p)

When the process time slice is exhausted, if the macro returns True (while the expired queue does not wait too long, see the new data structure Runqueue "Expired_timestamp"), the

Instead of entering the expired queue, the process remains in the active queue so that it can be dispatched to this interactive process as soon as possible. Dynamic precedence in Effective_prio when scheduling to the process

(): Prio=static_prio-bonus (Sleep_avg) (bonus (SLEEP_AVG) indicates that bonus is a function of sleep_avg, see "Priority computing Process"), and

Delta (p) is associated with the process's nice value and can be represented as delta (Nice). The relationship between bonus and Sleep_avg is illustrated in the "Priority Computing Process" section, with Delta and

The relationship between Nice is shown in the following figure:

The range of the Nice value is -20~19,delta (p) to convert it to -5~+5 plus a Interactive_delta constant: Task_nice (P) * MAX_BONUS/40 +

Interactive_delta, where Interactive_delta equals 2.
After conversion, task_interactive (p) becomes "Delta (Nice) is not more than bonus (SLEEP_AVG)". Representation of Sleep_avg as JIFFIES, and substituting constants

, Delta (Nice) <=bonus (SLEEP_AVG) can be expressed as:
Nice/4+2 <= bonus,-5<=bonus<=+5

As you can see, Nice is greater than 12 o'clock, and this inequality is constant false, which means that the process is never treated as an interactive process, and the higher the process static priority, the more it is treated as an interaction

The lower the SLEEP_AVG limit required for a process, the higher the static-priority process, the greater the chance of this reward.
4. The reward of ready waiting time
Because processes that are often in the task_interruptible state are most likely to be interactive, the length of time that this class of processes wakes up from hibernation and waits for scheduling on the ready queue is also

Will affect the dynamic priority of the process.

This work takes place after the scheduler (schedule ()) chooses this type of process, and considering that the interactive process is usually awakened during interrupts, the core also records the

A message that rewards a process that is not awakened by interrupts (see "Process average wait Time sleep_avg").

8. Dispatch device
With the above preparation, we can now look at the mainstream of the scheduler.
Compared with the 2.4 scheduler, the 2.6 schedule () function is simpler, reduces the lock operation, and the priority calculation is carried out outside the scheduler. To reduce the process of jumping between CPUs

Jump, 2.4 will be switched off the process of rescheduling to another CPU on the action also omitted. The basic flow of the scheduler can still be summed up in the same five steps:
Clean up the currently running process (prev)
Select the next process to run into (next)
Setting the running environment for a new process
Performing process Context Switching
Post finishing
The scheduler workflow for 2.6 retains many of the actions in the 2.4 system, and the details of the process switching are essentially the same as 2.4 (starting with Context_switch ()). In order not to be with the 2.4 series

The dispatcher analysis repeats, we analyze the scheduler's workflow according to the dispatcher's influence to each data structure, and focus on the different parts of the 2.4 scheduler, the same or similar

Part of the belief that readers combine code and the above technical analysis is easy to understand. At the same time, the 2.6 scheduler also adds support for load balancing and kernel preemption operations because the content is more independent

, we also put it in separate chapters.
1) Related locks
The main reason is that the ready queue is distributed to each CPU, and only two locks are involved in the 2.6 Scheduler: Ready queue lock Runqueue::lock, global core lock Kernel_flag. Right

The operation of the ready queue lock guarantees the operational uniqueness of the ready queue, and the core lock is the same as in 2.4: the scheduler should unlock the core lock before performing the switch

(Release_kernel_lock ()) to restore the lock status (Reacquire_kernel_lock ()) after the schedule has been completed. The lock state of the process is still stored in the Task_struct::lock_depth property

In
Because there is no global lock operation in the scheduler, the 2.6 scheduler itself has almost no operational obstacles.
2) Prev
The scheduler primarily affects the two properties of the Prev process:
The SLEEP_AVG subtracts the running time of the process (see "Processes that are switched down" for the average process waiting time sleep_avg);
Timestamp is updated to the current time, recording the time that is switched on to calculate the process wait time.
Prev is switched off, even if the SLEEP_AVG is modified, its position in the ready queue will not change, it will continue to participate in this priority scheduling until the state changes (such as hibernation

）。
3) Next
In the previous introduction of the RUNQUEUE data structure, we have analyzed the active/expired two priority-sorted Ready process queue function, 2.6 of the scheduler on the candidate

There are three possible ways to locate a process:
The process with the highest priority and the longest waiting time in the active ready queue;