Understanding process scheduling and process switching processes (Linux)

-----------------------------------------------------------------------------------

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

-----------------------------------------------------------------------------------

This experiment is to understand the process of process scheduling and process switching during the time tracking analysis process. This is the last experiment. We have to finish this experiment, or to have a certain understanding of task switching.

The Linux task switch is implemented through switch_to .

switch_to itself is a macro , by using the long jump instruction, when the operand of the long jump instruction is a TSS descriptive descriptor . Will cause the CPU's task to switch. At this point, the CPU saves the state of all registers to the TSS segment (Task status segment of the current task) pointed to by the current task register TR , and then uses the operand of the long jump instruction (TSS descriptive descriptor) to find the TSS segment of the new task , Then fill in the contents of each register, and finally. updates the TSS selector for the new task into the TR . This allows the system to formally start the task of performing a new switchover.

With this added, let's recall what we learned before.

Linux system, a process of the general operation of the process:

This is the process of switching from the executing user-state process x to executing the user-state process y .

1) The user-state process being executed x

2) An interrupt occurred int 0x80

3)Save_all //Save site

4) Schedule ()is called during interrupt processing or before the interrupt is returned, and the switch_to does a critical process context switch

5) After the label 1 starts to execute the user-state process y(where Y was previously switched out through the above steps so that it can continue from the label 1)

6)Restore_all //recovery site

7)Iret

8) Continue to execute user-state process y

But as we all know, here are a few special cases:

By interrupting the timing of the process, the user-state process and kernel threads switch between each other and kernel threads. Similar to the most common scenario, only interrupts during kernel thread execution are not transformed by the process user state and kernel state;

1) The kernel thread actively calls schedule (), with only the process context switching. There is no switch to the interrupt context. And the most general situation is slightly abbreviated.

2) Create a system call for the child process to run the starting point in the child process and return the user state. such as fork.

3) load a new running program and return to the user status, such as Execve.

Start the experiment

Based on previous knowledge. This time we trace the schedule function to analyze the process of the system process scheduling and process switching in detail.

Execute Menuos, set 3 breakpoints:schedule,context_switch,switch_to.

Execution stops at the first breakpoint, which is stopped at the schedule function. Use the List command to view its code, and the S command analyzes it by article. In the process. We need to look at the execution trajectory. A moment to analyze.

continues execution, stops at the second breakpoint, i.e. Context_switch stop at the place. Same as on, continue stepping.

In this process, pay attention to the switch_to.

Context_switch called the switch_to function, the SWITCH_TO macro definition. We are able to use the single-step operation into its internal observation.

Watermark/2/text/ahr0cdovl2jsb2cuy3nkbi5uzxqv/font/5a6l5l2t/fontsize/400/fill/i0jbqkfcma==/dissolve/70/gravity /center ">

Summarize

Switch_to the process of switching from a process to B processes such as the following:

Step1: copy two variables to register:

[prev] "a" (prev)

[Next] "D" (next)

This is also eax <== prev_a or eax<==%p (%ebp_a)

edx <== next_a or edx<==%n (%ebp_a)

Step2: Save the ebp and eflags of process a

PUSHFL / * Press the status register EFlags * /

PUSHL%EBP

Note that because ESP is now in the stack of a, they are stored in the kernel stack of the a process .

Step3: saves the current ESP to the a process kernel description descriptor:

Movl%%esp,%[prev_sp]\n\t /*save ESP * /

This is also prev_a->thread.sp<== esp_a

When Switch_to is called, Prev is a process-descriptive descriptor that points to its own process.

step4: the esp_bthat was saved from the descriptive descriptor of next (process B) before it was switched out from B.

MOVL%[next_sp],%%esp\n\t / * Restore ESP * /

This is also esp_b <==next_a->thread.sp

Note that next in the a process is a process that points to B describing the descriptor. From this point on, the process that the CPU is currently running is already a B process , because ESP already points to B's kernel stack. But. Today's EBP still points to the kernel stack of the a process , so all local variables are still local variables in a , for example, Next is essentially%n (%ebp_a), or next_a, which points to The process of B describes the descriptor .

step5: Save the instruction address labeled 1 to the IP domain of the a process descriptive descriptor:

movl $1f,%[prev_ip]\n\t / * Save EIP * /

This is also prev_a->thread.ip<==%1f

When the a process comes back from switch_to the next time. will start running from this command. The detailed method depends on the next instruction of B that is switched back.

STEP6: saves the return address to the stack. Then call the switch_to () function, and theswitch_to () function completes the hardware context switch.

PUSHL%[next_ip]\n\t / * RESTOREEIP * /

jmp switch_to\n / * Regparmcall * /

Note that, assuming B was also switch_to out before , [NEXT_IP] is the following 1f label , but assuming that process B has just been created . If you have not been switch_to before, then [NEXT_IP] will be ret_ftom_fork(see Copy_thread () function).

When switch_to () returns here, the return value Prev_a is written to %eax, which makes the EAX register in the SWITCH_TO macro always save the contents of prev_a, or, more precisely. is a "pointer" to a process descriptive narrative.

STEP7: after returning from Switch_to () continue to run from the 1: label, change the EBP to b kernel stack. Restore the eflags of B:

popl%%ebp\n\t / * Restore EBP * /  

popfl\n /*restore Flags * *

Assume that the execution continues from here after Switch_to () is returned. So before this, B must have been switch_to paged out, so it was definitely backed up Ebp_b and Flags_b, here to perform recovery operations.

At this point, EBP has pointed to the kernel stack of B, so local variables such as the above Prev,next are not already in the a process stack, but in the B process stack (b) before the last time it was switched out, there are also these two variables. So it represents the value of prev, next in the B stack, because prev==%p (%ebp_b), and before B was last switched out, the location holds the descriptive descriptor address of the B process.

Assuming this is the end of the switch_to, the prev variable in the later code (the code after switch_to in the Context_switch () function) points to the B process, so that process B does not know which process to switch back from. In the code after switch_to from Context_switch (), we see that Finish_task_switch (This_rq (), prev) needs to know which process was switched from before, so We have to find a way to save the descriptive descriptor of a process to the stack of B. This is the last function.

STEP8: writes eax to last. To save the correct prev information in the stack of B .

"=a" (last)

This is last_b <==%eax .

The method of calling switch_to from context_switch () is:switch_to (Prev,next, prev);

So, this last is essentially prev, so after SWITCH_TO macro run, Prev_b is the correct process of a descriptive narrative. Here, last is the equivalent of copying a process descriptor address from the process a stack to the stack of process B.

So far. Switch_to has finished running , a stops running. and start running B. Thereafter, it may be in a schedule. A call to Switch_to (C,A) occurs when process A is dispatched. At this point, a is dispatched again, after being dispatched. A process starts running from the code behind Switch_to in Context_switch (), when it sees the prev_a that will point to the process descriptor of C.

-------------------------------------END----------------------------------------

Liu Jianxin + Original works reproduced please specify the source + "Linux kernel analysis" MOOC course

http://mooc.study.163.com/course/USTC-1000029000

-----------------------------------------------------------------------------------

Understanding process scheduling and process switching processes (Linux)