20135302 Wei quiet--linux course Eighth Week experiment and summary

Eighth week of Linux course experiment and summaryExperiment and study summary 1. Implementation of process switching in the kernel

Process switching in Linux is a common operation that is implemented in the kernel.

There are three opportunities to achieve this:

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

Thread switching in the Linux kernel is implemented primarily through the schedule () function.

Schedule () function

• • Call Schedule () to execute the schedule () function when switching
  • Use struct task_struct *tsk = current; To obtain the current process; Sched_ submit _work (TSK); Avoid deadlocks; finally call _schedule () to handle the switching process
  • Next = Pick_ Next _task (RQ, prev);, _ Schedule () is used to determine which process is used to schedule the policy. But always choose the next process to switch, that is, according to the scheduling policy to select one of the highest priority task to make it the next process, and finally call the context _switch for the process context of the switchover process.

Context_switch

• • Process Context Switch
  • Where the Prepare_ task _ switch () function is the preparation before the switch is completed, then it is later determined that the current process is not a kernel thread, and if it is a kernel thread, it does not need to switch contexts.
  • Then call SWITCH_MM () and switch the virtual memory from one process map to the new process.
  • Call switch_to () to switch from the processor state of the previous process to the processor state of the new process. This includes saving, resuming stack information, and register information.

Switch_to

• • Switch_to is a macro, not a function, its parameter prev, next, last is not a value copy, but a local variable of its caller Context_switch ().
  • Local variables are indexed by%EBP registers, that is, by N (%EBP), n is the compile-time decision, and N is the same local variable in the same piece of code in different processes. In Switch_to, a stack switchover occurred, that is, EBP changed, so pay extra attention to which process the local variable belongs to at any one time. The call to the __switch_to () function is not implemented by ordinary calls, but by direct jmp, where the function parameters are not passed through the stack, but are passed through registers.

Process switching:

• • , A is the process that is running at this time (prev), and B is the process to be switched (next). The switchover process is divided into four steps:

    The first step: Movl%%esp,%0 is to save the value in the Register ESP in the THREAD.ESP of process A.

    The second step: Movl%3,%%esp is to assign the value of the thread.esp of process B to register esp. (This is actually the result of the first step of the last time you switched away from B.) In order to return, it must be considered for the future. ）

    The third step: that is, MOVL $1f,%1 which 1f means that the program is labeled 1, the location of the code labeled 1 is saved to a thread.eip.

    Fourth step: pushl% 4, the value of the THREAD.EIP of process B is stacked, when ESP points to a stack that is already process B. (In fact, the THREAD.EIP is the result of the third step of the last switch from B, which is the position of the label.) So any process recovery run, first of all definitely is the code that executes the designator 1. ）

    PUSHL%4 After a code is reversed jmp __switch_to and __switch_to is a function, he will have a RET after the completion of the operation, the first address in the stack as a function return address, so will jump to the label 1 where to execute the code.

    Since the __switch_to code is in schedule (), and the Shedule () function is in another system call function, such as sys_exit (), it is first returned to the schedule () that called the last switch of the B process. It is then returned to the system call function that calls schedule (), and finally the system call is called in the user space, all the places returned to the system call, and then the code for the user space is executed. This is a complete return to the B process. Note that because the return path at this time is returned based on the return address saved in the B stack, it is definitely returned to the B process.

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)

2.Linux System General Execution process

The most common scenario: a running process x switches to the process of running process y

• • Running user-state process X

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

  • Save_all//Save site

• • Schedule () is called during interrupt processing or before an interrupt is returned, where SWITCH_TO does a critical process context switch

• • • ASM Volatile("pushfl\n\t"/ * Save Flags * /
    • "PUSHL%%ebp\n\t"/ * Save EBP */ \
    • "Movl%%esp,%[prev_sp]\n\t"/ * Save ESP */ \
    • "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 */ \
    • "popfl\n"/ * Restore flags * /
    • / * OUTPUT parameters */ \
    • : [prev_sp] "=m" (prev->thread. sp),
    • [PREV_IP] "=m" (prev->thread. IP),
    • "=a" (last),/ * Input parameters: * /
    • : [next_sp] "M" (next->thread. sp),
    • [NEXT_IP] "M" (next->thread. IP),

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

  • Restore_all//Recovery site

  • Iret-pop cs:eip/ss:esp/eflags from kernel stack

  • Continue to run user-state process y

  • CPU Execution Status:

Several special cases

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

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

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

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

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.

Linux is a multi-process operating system, so other processes must wait until the running process is idle for the CPU to run. When a running process waits for other system resources, the Linux kernel gains control of the CPU and allocates the CPU to other waiting processes, which is the process switch. The scheduling algorithm in the kernel determines which process the CPU is allocated to.

The Linux system has a process table, and a process is one of them. Each item in the Process Control table is a TASK_STRUCT structure that stores a variety of low-level and advanced information in the TASK_STRUCT structure, including links from the registers of some hardware devices to the working directory of the process. The Process Control table is both an array, a doubly linked list, and a tree, and its physical implementation is a static array that includes multiple pointers. Once the system is started, the kernel is typically represented as a process. A global pointer variable, pointing to Task_struct, is used to record a running process. The variable current can only be changed by the process scheduler in KERNEL/SCHED.C.

Reference:

How does the Linux operating system work? The secret of cracking the operating system

20135302 Wei quiet--linux course Eighth Week experiment and summary