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

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

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

• 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

general execution of Linux systemsThe 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

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;

Basic concepts of Linux operating system architecture and system execution process operating system

Operating system: A basic set of programs contained in any computer system

• Kernel (process management, process scheduling, interprocess communication mechanism, memory management, interrupt exception handling, file system, I/O system, network part)
• Other programs (function libraries, shell programs, system programs, and so on)

The purpose of the operating system

• Interact with hardware, manage all hardware resources
• Provides a good execution environment for user programs (applications)

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;

Use GDB trace to analyze a schedule () function to verify your understanding of Linux system process scheduling and process switching process, and recommend to complete the experiment in the lab Building Linux virtual Machine environment.

Special attention and careful analysis of the assembly code in the Switch_to, understanding the process context of the switching mechanism, as well as the relationship with the interrupt context switch;

Experiment:

1. Purpose of the experiment

• Select a system call (except for the 13th system call time), the system invocation list, using the same system call using the Library function API and the C code to embed the assembly code in two ways
• Analyze the working process of calling system calls from assembly code, especially the way parameters are passed.
• Clarify your understanding of the "mechanism of system invocation".

2.1 Fork function in experimental process

This experiment chooses the fork system call, whose system call number is:

2    i386    fork            sys_fork            stub32_fork

A process, including code, data, and resources assigned to the process. The fork () function creates a process that is almost identical to the original process through a system call, that is, two processes can do exactly the same thing, but two processes can do different things if the initial parameters or the variables passed in are different. After a process calls the fork () function, the system first assigns resources to the new process, such as space for storing data and code. All the values of the original process are then copied to the new new process, with only a few values that are different from the value of the original process. The equivalent of cloning a self.

A wonderful thing about a fork call is that it is called only once, but it can return two times, and it may have three different return values:

1. In the parent process, fork returns the process ID of the newly created child process;
2. In a child process, fork returns 0;
3. If an error occurs, fork returns a negative value;

After the fork function finishes executing, if the new process is created successfully, there are two processes, one child process and one parent process. In the subprocess, the fork function returns 0, and in the parent process, fork returns the process ID of the newly created child process. We can determine whether the current process is a child process or a parent process by the value returned by the fork. Quote a netizen to explain why the value of Fpid is different in the parent-child process. "In fact, the equivalent of a linked list, the process forms a linked list, the parent process fpid (p means point) to the process ID of the child process, because the child process has no child process, so its fpid is 0.

The code for FORK.C is as follows:

#include <unistd.h>#include <stdio.h>int main (){    pid_t fpid;    int count = 0;    fpid = fork();    if (fpid < 0)        printf("error in fork!");    else if (fpid == 0) {        printf("i am the child process, my process id is %d\n",getpid());        count++;    }    else {        printf("i am the parent process, my process id is %d\n",getpid());        count++;    }    printf("count: %d\n",count);    return 0;}

Execution results

Using API and embedded assembly code to call fork, the result

After a successful creation of a new process, there are two fundamentally identical processes in the system, which do not have a fixed sequencing and which process first executes the process scheduling policy to look at the system. Each process has a unique (distinct) process ID, which can be obtained through the getpid () function, a variable that records the PID of the parent process, and the value of the variable can be obtained through the getppid () function. After the fork executes, there are two processes, and the variable for process 1 is count=0,fpid! =0 (parent process). The variable for process 2 is count=0,fpid=0 (child process), the variables of both processes are independent, there are different addresses, not shared, and this should be noted. We can say that we are using fpid to identify and manipulate parent-child processes. Others may wonder why the code is not copied from # include, because Fork is a copy of the current situation of the process, and when the fork is executed, the process has finished executing int count=0;fork only the next code to execute to the new process.

3. Experimental analysis

The following focuses on the implementation of embedded assembly code, FORK-ASM.C source code is as follows:

#include <unistd.h>#include <stdio.h>int main (){    pid_t fpid;    int count = 0;    asm volatile (            "mov $0, %%ebx\n\t"            "mov $0x2, %%eax\n\t"            "int $0x80\n\t"            "mov %%eax, %0\n\t"            : "=m" (fpid)            );    if (fpid < 0)        printf("error in fork!");    else if (fpid == 0) {        printf("i am the child process, my process id is %d\n",getpid());        count++;    }    else {        printf("i am the parent process, my process id is %d\n",getpid());        count++;    }    printf("count: %d\n",count);    return 0;}

The main difference between the above procedure and the FORK.C is that the ASM assembly is substituted for the fpid = fork () statement. The main process is:

    asm volatile (            "mov $0, %%ebx\n\t"        // 由于fork函数调用不需要参数，可直接将立即数0赋值给ebx，代表NULL。没有这条语句应该也可以。            "mov $0x2, %%eax\n\t"    // 系统调用号默认通过eax传递，因此将fork的系统调用号0x2赋值给eax            "int $0x80\n\t"                  // 通过0x80中断向量，执行系统调用。系统由eax此时的值可知，用户请求fork调用。            "mov %%eax, %0\n\t"      // 系统返回的pid号默认储存在eax中，将eax的值赋给第一个输出操作数，即下面的fpid。            : "=m" (fpid)                     // =代表操作数在指令中是只写的，m代表内存变量。即输出操作数0为内存中的fpid。            );

In addition to the system call number, most system calls also require some external parameters to be lost. Therefore, when an exception occurs, these parameters should be passed from user space to the kernel. The simplest way to do this is to store the parameters in the registers as if they were passing the system call number. On x86 systems, EBX, ECX, edx, ESI, and EDI store the first five parameters in order. It is rare to need six or more than six parameters, at which point a separate register should be used to hold pointers to all of these parameters in the user-space address. The return value to the user space is also passed through the register. On the x86 system, it is stored in the EAX register. The next many descriptions of the system invocation handlers are for the x86 version. But don't worry, the implementation of all architectures is very similar.

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