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

5) activated
Indicates why the process enters the ready state for whatever reason, which affects the calculation of the scheduling priority. Activated has four values:
-1, the process is awakened from the task_uninterruptible state;
0, the default value, the process is already in a ready state;
1, the process is awakened from the task_interruptible state and is not in the interrupt context;
2, the process is awakened from the task_interruptible state and in the interrupt context.
The activated initial value is 0, modified in two places, one in schedule (), is restored to 0, and the other is Activate_task (), which is called by the try_to_wake_up () function to activate the hibernation process:
If it is the Activate_task () called by the Interrupt Service program, which means that the process is activated by an interrupt, the process is most likely interactive, so place the activated=2 or activated=1.
If the process is awakened from the task_uninterruptible state, then Activated=-1 (in the TRY_TO_WAKE_UP () function).
The specific meaning and use of the activated variable is shown in the "Optimized priority calculation method".
6) Sleep_avg
The average wait time of the process (in nanosecond), between 0 and Ns_max_sleep_avg, the initial value is 0, which corresponds to the difference between the process wait time and the elapsed time. The sleep_avg represents a richer meaning that can be used to evaluate the "degree of interaction" of the process and to indicate the urgency of the process's need to run. This value is the key factor for dynamic priority computing, and the larger the SLEEP_AVG, the higher the calculated priority of the process (the smaller the number). The SLEEP_AVG process is analyzed in detail in the "process average wait time sleep_avg" below.
7) Interactive_credit
This variable records the "degree of interaction" of the process, taking a value between-credit_limit and credit_limit+1. When a process is created, the initial value is 0, and then 1 minus 1 according to different conditions, once it is over Credit_limit (which can only be equal to credit_limit+1), it does not come down again, indicating that the process has passed the "interactive" test and is considered an interactive process. Interactive_credit the specific process of change is described in detail in the "more precise interactive process priority".
8) NVCSW/NIVCSW/CNVCSW/CNIVCSW
Process switch count.
9) Time_slice
The time slice balance of the process is equivalent to 2.4 counter, but no longer directly affects the dynamic priority of the process. The behavior of Time_slice is specifically analyzed in "New Runtime Performance".
First_time_slice)
0 or 1 to indicate whether the first time slice is owned (the process you just created). This variable is used to determine whether or not to return the remaining time slices to the parent process at the end of the process (see "New Run Time Slice performance").
One) run_list
As mentioned earlier, all the processes under each priority are arranged sequentially in the prio_array structure of the priority series, but in fact each element in the array is a list_head structure, and it is also list_head for each element in the list of table headers, where the link is task_ The run_list member in the struct. This is a space-saving, accelerated access trick: The scheduler finds the corresponding run_list in Prio_array, and then finds the corresponding task_struct by run_list a fixed offset in task_struct (see Enqueue_task ( ), Dequeue_task (), and operations in List.h.
) array
Record the active ready Queue (runqueue::active) for the current CPU.
Thread_info)
Some of the running environment information for the current process, where two members of the structure are closely related to scheduling:
Preempt_count: The initial value is 0 nonnegative counter, more than 0 means the core should not be preempted;
Flags: One of the tif_need_resched bits, equivalent to the need_resched attribute in 2.4, indicates that the scheduler should start as soon as possible if the current running process is 1.
In 2.4, the task_struct of each process is located at the top of the process's core stack (the lower portion), and the kernel can easily access the task_struct of the current process through the stack register ESP. In 2.6, the data structure named current still needs to be accessed frequently, but now the top of the process core stack holds the Thread_info attribute, not the complete task_struct. The advantage of this is that only the most critical, most visited environments are kept in the core stack (still two pages in size), while most of the task_struct content is stored outside the stack through the Thread_info::task pointer to facilitate expansion. Thread_info is distributed and accessed in exactly the same way as the task_struct in 2.4, and current needs to be asked:

/*  excerpt from [include/asm-i386/current.h] */
static inline struct task_struct *  get_current (void)
{
Return current_thread_info ()->task;
}
#define  current get_current ()
where Current_thread_info () is defined as:
/*  excerpt from [include/asm-i386/ thread_info.h] */
Static inline struct thread_info *current_thread_info (void)
{
struct thread_info *ti;
__asm__ ("andl %%esp,%0; ": "=r"   (TI)  :  "0"   (~8191ul));
return ti;
}