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

first, the Linux process scheduling time

1. Time of Process state transition: Process termination, process sleep;
2. When the time slice of the current process runs out (current->counter=0);
3. device drivers;
4. Processes are returned to the user state from interrupts, exceptions, and system calls.

second, the experiment

As you can see, when we set a breakpoint, we find that it is always scheduled and seems to be looping. It is very likely that the number No. 0 process and the INIT process are calling each other.

Third, analysis

The schedule () function selects a new process to run and invokes Context_switch for context switching, which calls switch_to for critical context switching.

The following is the SWITCH_TO code:

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*/\//pushes the stack base address of the current process -              "MOVL%%esp,%[prev_sp]\n\t"    /*Save ESP*/\//Save the current top of the stack and save it to Thread.sp . the              "MOVL%[next_sp],%%esp\n\t"    /*Restore ESP*/\//Put the next process stack top into the ESP register -              "MOVL $1f,%[prev_ip]\n\t"    /*Save EIP*/\//the EIP that holds the current process -              "PUSHL%[next_ip]\n\t"    /*Restore EIP*/\//pushes the starting point of the next process into the stack the top of the next process is its starting point - __switch_canary +              "jmp __switch_to\n"    /*Regparm Call*/     -              "1:\t"\//start execution of the first instruction of next process +              "popl%%ebp\n\t"        /*Restore EBP*/\//the reason for the pop is because the next process as a prev process was once push 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)

Iv. Summary

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

1. 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;

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

3. The system call that creates the child process starts in the subprocess and returns the user state, such as fork;

4. A situation in which a new executable program is loaded and returned to the user state, such as EXECVE;

Li Josen

Original works reproduced please indicate the source

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

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