The process of understanding process scheduling and process switching during the time-tracking analysis process

The process of understanding process scheduling and process switching during the time-tracking analysis process

Shahuzy

Original works reproduced please specify the source + "Linux kernel analysis" MOOC course http://mooc.study.163.com/course/USTC-1000029000

First, the experimental requirements

1. To understand the timing of process scheduling in Linux, you can search the kernel code for the schedule () function, see where the schedule () is called, and determine whether the summary of our course content is accurate;

2. Use GDB trace to analyze a schedule () function to verify your understanding of the process scheduling and process switching processes of Linux systems.

3. Pay particular attention to and carefully analyze the assembly code in Switch_to, understanding the switching mechanism of the process context, and the relationship to the interrupt context switch.

Second, the experimental process

1. Understand the switching mechanism of the process context and the relationship to the interrupt context switch

User-State process it does not directly invoke schedule () when it is in the user, because schedule is a kernel function, and it is not a system call, can not call it directly, only indirectly call it, the indirect call schedule () is the time to interrupt the processing process

For the user-state process, it is going to switch out from the current running process, then it must go into the interrupt, this interrupt is a general interrupt, there will be an outage before there is a possibility of process scheduling, so the general user-state process can only be passively dispatched

[kernel thread] can directly call schedule () for process switching, can also be scheduled during interrupt processing, that is, kernel threads as a class of special processes can be active scheduling, can also be passive scheduling;

The user-state process cannot implement the active scheduling, but can only be dispatched by a point in time after the kernel state, that is, scheduling during interrupt processing.

Scheduling timing of processes and switching of processes

The principle of operating system describes a large number of process scheduling algorithms, these algorithms from the perspective of implementation is only to choose a new process from the run queue, the process of selecting the use of different strategies.

It is more important to understand the working mechanism of the operating system than the process scheduling timing and process switching mechanism.

Timing of process scheduling

• Interrupt processing (including clock interrupts, I/O interrupts, system calls, and exceptions), call schedule () directly, or call schedule () based on the need_resched tag when returning to the user state;

• Kernel threads can directly call schedule () for process switching, or in the process of interrupt processing, which means that kernel threads as a special kind of process can be active scheduling, but also can be passively dispatched;

• The user-state process cannot implement the active scheduling, but can only be dispatched by a point in time after the kernel state, that is, scheduling during interrupt processing.

Switching of processes

• To control the execution of the process, the kernel must have the ability to suspend a process that is executing on the CPU and resume execution of a previously suspended process called process switching, task switching, context switching;

• Suspending a process that is executing on the CPU is different from saving the scene at the time of the outage, before and after the interrupt is in the same process context, but only by the user-state to the kernel state execution;

• The process context contains all the information required by the process execution

• User address space: Includes program code, data, user stack, etc.

• Control information: Process descriptor, kernel stack, etc.

• Hardware context (note that interrupts are also saved by the hardware context only if the method is saved differently)

• The schedule () function selects a new process to run and invokes Context_switch for context switching, a macro called SWITCH_TO for critical context switching

• Switch_to takes advantage of the prev and next two parameters: Prev points to the current process, and next points to the scheduled process

2, through the experiment, GDB Trace analysis of a schedule () function

Experimental process:

3. Analysis of assembly code in SWITCH_TO

The schedule () function selects a new process to run and invokes Context_switch for context switching, a macro called SWITCH_TO for critical context switching

Analyze assembly code:

*next = Pick_next_task (RQ, prev);//process scheduling algorithms encapsulate this function inside

*context_switch (RQ, Prev, next);//process Context switch

*switch_to takes advantage of the prev and next two parameters: Prev points to the current process, and next points to the scheduled process

ASM volatile ("pushfl\n\t" \

"PUSHL%?p\n\t" \ pushes the stack base address of the current process

"Movl%%esp,%[prev_sp]\n\t" \ Save the current stack top and save it to THREAD.SP.

"Movl%[next_sp],%%esp\n\t" \ Put the next process stack top into the ESP register

(44, 45 completes the kernel stack switch)

"Movl $1f,%[prev_ip]\n\t" \ Save EIP for current process

"PUSHL%[next_ip]\n\t" \ Presses the starting point of the next process into the stack

The top of the next process is its starting point.

__switch_canary \

"JMP __switch_to\n" \

(46-49 uses the next process stack, but still executes in the Prev process)

"1:\t" \ Start executing the first instruction of next process

The reason for the "popl%?p\n\t" \pop is that the next process as a prev process has been push

"Popfl\n"

Switching of processes:

(1) In order to control the execution of the process, the kernel must have the ability to suspend the process executing on the CPU and resume execution of a previously suspended process, which is called process switching, task switching, context switching;

(2) suspend the process that is executing on the CPU, is different from the Save field at the time of interruption, before and after the interruption is in the same process context, only by the user state to the kernel state execution;

(3) The process context contains all the information required for process execution

User address space: Includes program code, data, user stack, etc.

Control information: Process descriptor, kernel stack, etc.

Hardware context (note that interrupts are also saved by the hardware context only if the method is saved differently)

Iii. Summary of the experiment

Through this experiment, I understand the scheduling timing of the process, switch_to and corresponding stack state and so on. Among them, the key to understand:

The general execution of Linux systems takes two things:

The most common scenario: The running user-state process x switches to the process of running user-state process y

1. Running user-state process X

2. An interrupt occurred--save cs:eip/esp/eflags (current) to kernel Stack,then load Cs:eip (entry of a specific ISR) and SS:ESP (point to Kernel Stack).

3. Save_all//Save site

4. Schedule () is called during interrupt processing or before an interrupt is returned, where SWITCH_TO does a critical process context switch

5. The user-state process y is started after the label 1 (where Y has been switched out through the above steps so it can continue from label 1)

6. Restore_all//Recovery site

7. Iret-pop cs:eip/ss:esp/eflags from kernel stack

8. Continue to run user-state process y

Special Cases

By interrupting the timing of the processing process, the user-state process and kernel threads switch between each other and the kernel threads switch to each other, very similar to the most common situation, but the kernel thread is running in the process of interruption without process user state and kernel state conversion;

Kernel thread actively calls schedule (), only the process context of the switch, there is no interrupt context switch, and the most general situation is slightly abbreviated;

The system call that creates the child process starts in the subprocess and returns the user state, such as fork;

A situation in which a new executable program is loaded and returned to the user state, such as EXECVE;

The process of understanding process scheduling and process switching during the time-tracking analysis process