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

Li Yang Original Works reproduced please specify the source

"Linux kernel Analysis" MOOC course http://mooc.study.163.com/course/USTC-1000029000

This experiment is an in-depth understanding of the timing of process scheduling in Linux systems.

The Linux scheduler divides processes into three categories:

1. Interactive process

2. Batch Process

3. Real-time process

Linux uses different scheduling strategies based on the different classifications of the process. For real-time processes, a FIFO or Round Robin scheduling strategy is used. For normal processes, it is necessary to differentiate between interactive and batch-processing. Traditional Linux schedulers increase the priority of interactive applications, enabling them to be dispatched more quickly.

There are two main ways in which scheduling occurs:

1: Active scheduling (voluntary dispatch )

The Process Scheduler function schedule () is invoked directly in the kernel , and when a process needs to wait for a resource and temporarily stops running, it puts the state on hold (sleep) and proactively requests the dispatch to yield the CPU.

2: Passive scheduling (preemptive scheduling, forced scheduling)

User preemption and Kernel preemption

(1) User preemption occurs when the user space is returned from the system call and the user space is returned from the interrupt handler.

(2) Kernel preemption: In a system that does not support kernel preemption, once a process/thread is running in kernel space, it can be executed until it voluntarily discards or the time slice runs out. Such a very urgent process or thread will not run for a long time.

In the experiment, the schedule () function is analyzed specifically: It includes three processes:

• 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

The following is a concrete experiment to verify this process:

The first is to start the kernel and debug:

Then the schedule () function and the __schedule () function:

Furthermore, Context_switch ():

The last is the Switch_to macro definition, which can be observed by assembly instructions to preserve the register state:

The following is a detailed analysis of SWITCH_TO code:

First, simply mention the called relationship of the macro and function:

Schedule ()--Context_switch ()--switch_to, __switch_to ()

In this case, schedule is the keynote function, which involves some scheduling algorithms, which are not discussed here. Transitions between processes occur when schedule () needs to pause execution of a process and continue execution of the B process. There are two main parts of process switching: 1. Toggle the Global page table entry, 2, switch the kernel stack and the hardware context. This switching work is done by Context_switch (). Among them, switch_to and __switch_to () mainly completed the second part. In more detail, __switch_to () mainly completes the hardware context switch, switch_to mainly completes the kernel stack switch.

When reading switch_to, please note: This is a macro, not a function, its parameters prev, next, last is not a value copy, but its caller context_switch () local variables. Local variables are indexed by%EBP registers, that is, by N (%EBP), n is the compile-time decision, and N is the same local variable in the same piece of code in different processes. In Switch_to, a stack switchover occurred, that is, EBP changed, so pay extra attention to which process the local variable belongs to at any one time. The call to the __switch_to () function is not implemented by ordinary calls, but by direct jmp, where the function parameters are not passed through the stack, but are passed through registers.

Finally, you need to be aware that:

The code is common to all processes, and the code itself is not part of a particular process, so determine which process is currently not being executed by looking at which process the code is executing, but rather through the stack of which process the ESP points to. So, for the switch point in the diagram above, it is also possible to understand that, at this point, esp points to the stack of other processes, the current process is suspended, waits for some time, and when the ESP pointer again points back to the stack of the process, the process begins to run again.

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