Overview of Linux system architecture and execution process
1, Knowledge accumulation
1. Hard interrupt and soft interrupt
Hard interrupt: two pins of cpu (maskable and unshielded interrupt)
Soft interrupt:
- Fault: there is a problem, but it can be restored to the current command
- Exit: unrecoverable serious failure
- Trap: an exception actively generated by the program
2. There are two ways to call schedule():
- The process initiatively calls schedule, such as the system call that is blocked by the process, waiting for the peripheral or active sleep, and so on. Finally, it will be called to the schedule function in the kernel.
- Loosely called, schedule () can be called at any time in the kernel code to make the current kernel path (interrupt handler or kernel thread) give up the CPU; Also according to need_ The resched flag is used for process scheduling, and the kernel will detect need at the appropriate time_ The resched flag determines whether to call the schedule() function
3. Context
- The CPU runs in user space and executes the user process context
- The CPU runs in kernel space and is in the context of a process (usually a kernel thread)
- The CPU runs in kernel space and is in the context of interrupt (interrupt handler ISR, including system call processing procedure)
4. Timing of process scheduling
- The user process actively gives up the CPU through a specific system call
- The interrupt handler schedules when the kernel returns to user state
- The kernel thread actively calls the schedule function to give up the CPU
- The interrupt handler actively calls the schedule function to give up the CPU
5. Classification of processes 2:
- Interactive process: a large number of human-computer interaction, continuous sleep, and high requirements for system response time
- Batch process: no human-computer interaction, running in the background and occupying a lot of system resources
- Real time process: requires immediate response and execution
2, Experiment - timing of process scheduling and process switching
1. Configure the system running MenuOS
cd ~/LinuxKernel rm menu -rf git clone git://github.com/mengning/menu.git cd menu make rootfs
2. Debug
cd .. qemu -kernel linux-3.18.6/arch/x86/boot/bzImage -initrd rootfs.img -S -s
Create a new shell for gdb debugging
gdb file linux-3.18.6/vmlinux target remote:1234 b schedule b context_switch b switch_to b pick_next_task c
Run to schedule, which is the main function of process scheduling
context_ The switch function implements process switching.
pich_ next_ The task function is responsible for selecting the next process according to the scheduling policy and scheduling algorithm.
switch_to switch the process key context. The embedded code is as follows
asm volatile( "pushfl\n\t" //Save current process flags "pushl %%ebp\n\t" //Stack base address of current process "movl %%esp,%[prev_sp]\n\t" //Save ESP and save the current stack top "movl %[next_sp],%%esp\n\t" //Update ESP and save the next stack top to esp // Complete switching of kernel stack "movl $1f,%[prev_ip]\n\t" //Save the EIP of the current process "pushl %[next_ip]\n\t" //Push the starting point of the next process into the stack, that is, the top of the stack of the next process is the starting point __switch_canary //next_ The IP is generally $1f, and RET for newly created child processes_ from_ fork "jmp __switch_to\n" //In the prve process, the next process stack is set. Unlike call, jmp passes parameters through registers (call passes through the stack). Therefore, when ret pops up, it is the starting point of the next process previously pushed into the top of the stack //Complete EIP switching "1:\t" //The next process starts execution "popl %%ebp\n\t" //restore EBP "popfl\n" //restore flags //Output : [prev_sp] "=m" (prev->thread.sp), //Save esp of current process [prev_ip] "=m" (prev->thread.ip), //Save eip of current warehousing "=a" (last), //Register to destroy "=b" (ebx), "=c" (ecx), "=d" (edx), "=S" (esi), "=D" (edi) __switch_canary_oparam //Input quantity : [next_sp] "m" (next->thread.sp), //The top address of the kernel stack of the next process, that is, esp [next_ip] "m" (next->thread.ip), //eip of next process // regparm parameters for __switch_to(): [prev] "a" (prev), [next] "d" (next) __switch_canary_iparam : //Reload segment register "memory");
3, Summary
General execution process of Linux system.
The process of switching from running user state process X to user state process Y is described in detail
(1) Running user state process x
(2) In case of interruption (including exception, system call, etc.), the hardware completes the following actions.
save cs:eip/ss:esp/eflags: the current CPU context is pushed into the kernel stack of user mode process X.
load cs:eip(entry of a specific ISR) and ss:esp(point to kernel stack): load the kernel stack related information of the current process and jump to the interrupt handler, that is, the starting point of the interrupt execution path.
(3) SAVE ALL, save the scene. At this time, the interrupt context switching is completed, that is, from the user state of process x to the kernel state of process X.
(4) the schedule function is called in the interrupt processing process or before the interrupt is returned, of which switch_to makes a key process context switch. Switch the kernel stack of the current user process x to the kernel stack of the selected next process (assumed to be process y in this example), and complete the state switching of EIP and other registers required by the process context.
(5) After label 1, start running the user state process Y (where Y has been switched out through the above steps, so it can continue from label 1).
(6) restore all, restore the site, corresponding to the site saved in (3).
(7) IRET pop CS: EIP / SS: ESP / EFLAGS. Pop the hardware completed stack contents in (2) from the kernel stack of the Y process. At this time, the interrupt context switching is completed, that is, from the kernel state of process y to the user state of process y.
(8) Continue to execute user mode process Y.