Grasping Writer: Li Pengju No.: 20179203
(
original Works reproduced please specify the source )
(Study course: "Linux kernel Analysis" MOOC course http://mooc.study.163.com/course/USTC-1000029000)
First, the experimental requirements:
1. Understand the timing of process scheduling in Linux systems, you can search the kernel code for the schedule () function, see where the schedule () is called, to determine whether the summary of our course content is accurate;
2. Use GDB trace to analyze a schedule () function to verify your understanding of Linux system process scheduling and process switching process, and recommend to complete the experiment in the lab Building Linux virtual machine environment;
3. Pay special attention to and carefully analyze the assembly code in Switch_to, understand the switching mechanism of the process context, and the relationship with the interrupt context switch;
Second, the experimental process:
1, using the GDB Trace Analysis Schedule () function, first open the distribution execution kernel instructions.
Input directive: Qemu–kernel LINUX-3.18.6/ARCH/X86/BOOT/BZIMAGE–INITRD Rootfs.img–s–s:
2. Then open another terminal and enter the following command:
gdb(gdb)file linux-3.18.6/vmlinux(gdb)target remote:1234(gdb)b schedule(gdb)c
Debug and trace the execution process of schedule;
Then set breakpoints at the appropriate location to observe:
Third, the experimental Knowledge point summary:
Process scheduling, first enter the schedule () function, a task_struct struct pointer tsk assigned to the current process and then call Sched_submit_work (tsk) We enter this function, to see what we did in the implementation of the Sched_ Submit_work, input Si enter function, you can see this function when the detection of Tsk->state is 0 (runnable) If the run state is returned tsk_is_pi_blocked (tsk), detect tsk deadlock detector is empty, Return if it is not empty. Then detect if the plug queue needs to be refreshed to avoid deadlocks sched_submit_work primarily to avoid deadlocks and then we enter the __schedule () function.
Then I opened the switch_to.h directly, and CORE.C observed Switch_to's call:
We see the use of switch_to (Prev,next,prev) in context_switch to switch processes.
Switch_to is a macro definition that completes the switch from Prev to next, saves the flags first, then saves the current process's EBP, then saves the current process's ESP to PREV->THREAD.SP, and then saves the address of the label 1: to the prev- The >thread.ip. Then press the NEXT->THREAD.IP onto the stack. Here, if the previous B was also switch_to out, then the NEXT->THREAD.IP is the following 1f label, but if the next process has just been created, not switch_to out before, that next-> Thread.ip will be the Canary technology that ret_ftom_fork__switch_canqry should be the modern operating system to prevent stack overflow attacks.
JMP __switch_to uses Regparm call, which is not pressed into the stack, but instead uses register values to invoke __switch_to
EAX store Prev,edx store next. Why not use the call __switch_to in JMP, because calls will cause the address of the following sentence (that is, 1:) to press the stack, and then __switch_to () must only RET to here, and can not be as needed ret to ret_from_fork. When a process is dispatched again, it starts from 1: Executes, pops the EBP, and pops the flags.
This experiment lets us see how Linux processes the process and when it is scheduled to switch. We studied several process scheduling functions and saw how the system was processed and recovered in the event of a deadlock condition. Process scheduling is the most important operation of the operating system, only system calls to ensure that the operating system quickly run multiple tasks, so that multiple tasks at the same time, so that the operating system can make sense, to meet the user to open multiple programs at the same time, a variety of tasks, not long wait.
2017-2018-1 20179203 "Linux kernel Fundamentals and Analysis" Nineth Week assignment