The eighth week process switching and the general execution process of the system

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

1. Implementation of process switching in the kernel

Process switching in Linux is a common operation that is implemented in the kernel. Here we analyze how this operation is implemented in the kernel.

Thread switching in the Linux kernel is implemented primarily through the schedule () function. The timing of implementation has the following three opportunities

• 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.

Process switching requires saving information about the process to be switched, but this is different from interrupts because the interrupt is in one process and the switching process needs to switch between the different processes. The data you need to save during the process switchover is as follows

• 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 code involved in the process switching is as follows

• 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

The flowchart of its operation is as follows:

2. Experiments and Code Analysis

Experiment with the menu code of the previous weeks, setting breakpoints on schedule, Pick_next_task, Context_switch functions, and discovering switch by watching Context_switch (RQ, prev, next) _TO This macro definition is located in Context_switch. The following is an experiment where you can see that in schedule, Pick_next_task, context_switch functions are called in turn.

Here the process save data is mainly located in the Switch_to macro definition, the code is as follows

1 #defineSwitch_to (prev, Next, last)2      Do {                                 3         /*                              4 * context-switching clobbers all registers, so we clobber5 * them explicitly, via unused output variables. 6 * (EAX and EBP isn't listed because EBP is saved/restored7 * Explicitly for Wchan access and EAX are the return value of8 * __SWITCH_TO ())9          */                                TenUnsignedLongebx, ecx, edx, ESI, EDI;  One          AAsmvolatile("pushfl\n\t"      /*Save Flags*/    -                 "PUSHL%%ebp\n\t"        /*Save EBP*/  -                 "MOVL%%esp,%[prev_sp]\n\t"  /*Save ESP*/  the                 "MOVL%[next_sp],%%esp\n\t"  /*Restore ESP*/  -                 "MOVL $1f,%[prev_ip]\n\t"    /*Save EIP*/  -                 "PUSHL%[next_ip]\n\t"   /*Restore EIP*/     - __switch_canary +                 "jmp __switch_to\n"  /*Regparm Call*/  -                 "1:\t"                         +                 "popl%%ebp\n\t"     /*Restore EBP*/     A                 "popfl\n"         /*Restore Flags*/   at                  -                 /*Output Parameters*/                 -: [PREV_SP]"=m"(prev->thread.sp), -[PREV_IP]"=m"(prev->Thread.ip), -                 "=a"(last), -                  in                 /*clobbered output registers:*/      -                 "=b"(EBX),"=c"(ECX),"=d"(edx), to                 "=s"(ESI),"=d"(EDI) +                  - __switch_canary_oparam the          *         /*Input Parameters:*/                 $: [NEXT_SP]"m"(next->thread.sp),Panax Notoginseng[NEXT_IP]"m"(next->Thread.ip), -          the         /*regparm parameters for __switch_to ():*/   +[Prev]"a"(prev), A[Next]"D"(Next) the          + __switch_canary_iparam -          $:/*Reloaded Segment Registers*/            $         "Memory");  -} while(0)

Here you can see that the SWITCH_TO code mainly implements the saving work in the process of switching between processes. This form of macro definition is primarily intended to be compatible with the C language, and the ending format. From the three parameters defined by the SWITCH_TO macro, you can see that the pre refers to a forward process, and next refers to the backward process. The main implementation of line 12-22 is to ebp,esp,eip the pre process into the stack, and then assign the value of next to Ebp,esp,eip. After that, it's about the input of the information about the previous process, the process that you want to switch. (The specific grammar can not understand.) ORZ)

3. Summary

The switching of the implementation process in the Linux kernel is mainly achieved by saving the process-related information, and it is necessary to pay attention to the difference between the kernel-level process switching and the user-state process switching in process switching. Kernel states can call the schedule function directly without having to break into the process. The user state needs to be trapped in the kernel state to enable the process to switch. From this function of switch_to, we can also verify that the inference of the relevant information is saved when our process is switched.

The eighth week process switching and the general execution process of the system