1, Process scheduling and process switching in Linux system

(1) Process mobilization

1. In the interrupt processing process (including clock interrupt, I/O interrupt, system call and exception), directly call schedule or return to user status according to need_ The resched tag calls schedule.
2. The kernel thread can directly call schedule for process switching or scheduling during interrupt processing, that is to say, as a special process, the kernel thread can be actively scheduled or passively scheduled.
3. User state processes cannot be actively scheduled. They can only be scheduled at a certain time point after falling into kernel state, that is, during interrupt processing.

(2) Process switching

1. In order to control the execution of a process, the kernel must be able to suspend the process executing on the CPU and resume the execution of a previously suspended process, which is called process switching, task switching and context switching, that is, process context switching. Suspending the process being executed on the CPU is different from saving the scene during interrupt. Before and after interrupt, it is in the same process context, but it is executed from user state to kernel state. The process context contains all the information needed for process execution.

• User address space: including program code, data, user stack, etc
• Control information: process descriptor, kernel stack, etc
• Hardware context (note that the hardware context should also be saved for interrupts, but the saving methods are different)

2. The schedule () function selects a new process to run and calls context_switch performs context switching. This macro calls switch_to switch key contexts.

• next = pick_next_task(rq, prev);// Process scheduling algorithms are encapsulated inside this function
• context_switch(rq, prev, next);// Process context switching
• switch_to uses two parameters prev and next: prev points to the current process and next points to the scheduled process

(3) switch to code analysis

asm volatile("pushfl\n\t"      /* Save the flags of the current process */   
           "pushl %%ebp\n\t"        /*Push the ebp of the current process into the stack of the current process */ 
           "movl %%esp,%[prev_sp]\n\t"  /* Save the current process ebp to the current process prev - > thread.sp */ 
           "movl %[next_sp],%%esp\n\t"  /* Assign the esp value of the next process to the esp register */ 
           "movl $1f,%[prev_ip]\n\t"    /* Save the address of the 1: code stored in memory to prev - > thread.ip   */ 
           "pushl %[next_ip]\n\t"   /* Push the eip of the next process onto the stack   */    
           __switch_canary                   
           "jmp __switch_to\n"  /* regparm call  */ 
           "1:\t"                        
           "popl %%ebp\n\t"     /* restore EBP   */    
           "popfl\n"         /* restore flags */  

           /* output parameters */                
           : [prev_sp] "=m" (prev->thread.sp),     
             [prev_ip] "=m" (prev->thread.ip),        
             "=a" (last),                 

             /* clobbered output registers: */     
             "=b" (ebx), "=c" (ecx), "=d" (edx),      
             "=S" (esi), "=D" (edi)             

             __switch_canary_oparam                

             /* input paraeters: */                
           : [next_sp]  "m" (next->thread.sp),        
             [next_ip]  "m" (next->thread.ip),       

             /* regparm parameters for __switch_to(): */  
             [prev]     "a" (prev),              
             [next]     "d" (next)               

             __switch_canary_iparam                

           : /* reloaded segment registers */           
          "memory");                  
}

2, Use gdb trace to analyze a schedule() function

1. Run the following commands successively in the shell to obtain the code of this experiment and compile and run it

cd LinuxKernel

rm menu -rf

git clone https://github.com/mengning/menu.git

cd menu

mv test_exec.c test.c

make rootfs 

The operation results are as follows:

2. Close the QEMU window, go back to the Linux kernel directory in the shell window, use the following command to start the kernel and stop before the CPU runs the code for debugging

cd .. //Go back to the Linux kernel directory

qemu -kernel linux-3.18.6/arch/x86/boot/bzImage -initrd rootfs.img -s -S //Boot kernel

gdb //debugging

file linux-3.18.6/vmlinux //load file

target remote:1234 //Establish a connection between gdb and gdb server

3. Set breakpoint tracking analysis schedule function

3, Summary

(1) There are three types of process scheduling opportunities:

• In the interrupt handling process (including clock interrupt, I/O interrupt, system call and exception), directly call schedule (), or return to user status according to need_ The resched tag calls schedule()
• The kernel thread can directly call schedule() for process switching, and can also be scheduled during interrupt processing. That is to say, as a special process, the kernel thread can be actively scheduled or passively scheduled
• User state processes cannot be actively scheduled. They can only be scheduled at a certain time point after falling into kernel state, that is, during interrupt processing

(2) The process context contains all the information required for process execution, including the following

• User address space: including program code, data, user stack, etc
• Control information: process descriptor, kernel stack, etc
• Hardware context (different from the method of interrupting and saving hardware context)

(3) The most general case of process scheduling
Switching from running user state process X to running user state process Y:

1. Running user state process X
2. Interrupt occurs - 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 the scene
4. schedule() is called before interrupt processing or interrupt is returned, switch_ of which To makes a key process context switch
5. After label 1, start running user state process Y (here Y has been switched out through the above steps, so it can continue from label 1)
6. restore_all / / restore the scene
7. iret - pop cs:eip/ss:esp/eflags from kernel stack
8. Continue running user mode process Y

(4) Several special cases of process scheduling

1. Through the scheduling opportunity in the interrupt processing process, the user state processes and kernel threads switch with each other and the kernel threads switch with each other, which is very similar to the most general situation, except that the interrupt occurs during the operation of the kernel thread, and there is no process user state and kernel state conversion
2. The kernel thread actively calls schedule(), only the process context is switched, and the interrupt context is not switched, which is slightly different from the most general case
3. The execution starting point and return user status of the system call creating the sub process in the sub process, such as fork
4. Return to user status after loading a new executable program, such as execve