The seventh week of the Linux kernel analysis notes process switching and the general execution process of the system

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

The timing analysis of process scheduling and process scheduling

1. Process scheduling

Different types of processes have different scheduling requirements

　　 The first kind of classification：
I/o-bound
Frequent I/O
It usually takes a lot of time to wait for I/O operations to complete
Cpu-bound
COMPUTE-intensive
Requires a lot of CPU time to perform operations
　　 The second type of classification：
Batching process (batch processing)
No need to interact with the user, usually running in the background
No need to respond quickly
Typical batch process: compiler, scientific calculation
Real-time processes (real-time process)
Have real-time requirements and should not be blocked by low-priority processes
Short response times and stability
Typical real-time processes: Video/audio, mechanical control, etc.
Interactive processes (Interactive process)
Requires frequent interaction with the user, so it takes a lot of time to wait for user input actions
Response time is faster and average latency is lower than 50~150ms
Typical interactive programs: shell, text editing programs, graphics applications, etc.

The scheduling algorithm related code in the kernel uses a policy pattern similar to Ood.

2, the 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.

Second, process context switch related code analysis

1, the process of switching

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

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

3) 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)

4) 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

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

2. Code Analysis

Key Assembler Code:

OUTOUT:THREAD.SP: Kernel state, SP is the stack top of the kernel stack

Thread.ip: EIP for current process

INPUT:PREV_SP: Stack top of the kernel stack for the next process

PREV_IP: The starting point for the next process execution

These two sentences complete the kernel stack switch, save the stack top of the current kernel stack, put the stack of the next next process into the ESP register, and then the stack action is done in the next process stack:

NEXT_IP is generally $1f, which is ret_from_fork for newly created child processes.

Third, the general implementation of the Linux system process

1, the most general situation: The running user-state process x switch to the process of running user-state process y

• Running user-state process X
• 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).
• Save_all//Save site
• Schedule () is called during interrupt processing or before an interrupt is returned, where SWITCH_TO does a critical process context switch
• 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)
• Restore_all//Recovery site
• Iret-pop cs:eip/ss:esp/eflags from kernel stack
• Continue to run user-state process y

2. Several 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;

Next_ip=ret_from_fork

3, the process of the address space is a total of 4G, wherein 0--3G is user-state can be accessed, more than 3G only the kernel state can access

Iv. Overview of the system architecture and implementation process

1. System Architecture

2. Architecture of a typical Linux operating system

3, the simplest is the most complex operation--ls

4, CPU and memory angle to see the implementation of Linux system

1. Execute the gets () function;
2. System call, fall into the kernel state, will be eip/esp/cs/ds and other information compression stack.
3. Process management: Wait for keyboard typing instructions. Waiting for input, the CPU dispatches other processes to execute while wait for an I/O interrupt;
4. Hit LS, send I/O interrupt to the CPU, interrupt processing program for on-site storage, pressure stack and so on;
5. The interrupt handler discovers that the X process is waiting for this I/O (at which point X has become blocked) and the handler sets X to Wake_up;
6. Process management may set process X as the next process;
7. The system call to get () gets the data read from the keyboard and returns the user state.

From a memory point of view, all physical addresses are mapped to more than 3G of address space: Because this part is shared for all processes

0xc0000000 The following is part of the 3G, user-state.

Five, the experiment

Use GDB trace to analyze a schedule () function to verify the understanding of Linux system process scheduling and process switching process

Close the Qemu window, in the Shell window, the CD Linuxkernel back to the Linuxkernel directory, start the kernel with the following command and stop for debugging before the CPU runs the code:

Qemu-kernel LINUX-3.18.6/ARCH/X86/BOOT/BZIMAGE-INITRD Rootfs.img-s-S

Next, we can split a new shell window horizontally, then start GDB debugging with the following command

Gdb

(gdb) file Linux-3.18.6/vmlinux

(GDB) Target remote:1234

and set a breakpoint at the entrance of the kernel function schedule, and then enter C to continue execution, then the system can stop at the function, then we will be able to use the command n or S step-by Trace, you can explore the pick_next_task,switch_to and other functions of the execution process

Set breakpoints at schedule:

Vi. Summary

Through learning, we learned that Linux uses the stack for process scheduling. Schedule () regain the large kernel lock when needed, re-enable kernel preemption, and check if some other process has set the TLF_NEED_RESCHED flag for the current process, and if so, the entire schedule () function restarts, otherwise the function ends. The core function of the Linux dispatch encapsulates the framework of the kernel scheduler for the Schedule,schedule function. The detail implementation invokes the function implementation in the specific scheduling class. When the switching process has been selected, the processing of the user's virtual space begins, and then the process switches switch_to (). The so-called process switching is mainly the switch of the stack, which is done by the macro operation Switch_to ().

Linux kernel Analysis Seventh week note process switching and general execution of the system