Linux context switch Analysis notes

Linux context switch Analysis notes-general Linux technology-Linux programming and kernel information. The following is a detailed description. 1. Kernel stack switching (MIPS)
When the scheduling switches to a process, set * kernelsp based on the value of task_struct-> thread_info (the kernel stack bottom of the currently running process ), the value is thread_info + THREAD_SIZE-32 (in MIPS, use the set_saved_sp macro ).

2. Saving of exception and interrupt registers (MIPS)
When you use SAVE_SOME to save the context, if you find that the core State is switched from the user State, use the get_saved_sp macro to put * kernelsp into the sp. Then, the kernel stack is allocated with the size of PT_SIZE (= sizeof (struct pt_regs) as the storage space of the context. All data is carefully organized during storage, and finally a struct pt_regs structure.

If the user State --> kernel state, k0 = sp, sp = * kernelsp-PT_SIZE, store k0, PT_R29 (sp), and save other registers.

For kernel state --> kernel state, k0 = sp, sp = sp-PT_SIZE, store k0, PT_R29 (sp), and then save other registers.

3. Save the task switching context (MIPS)
After the clock is interrupted, use SAVE_SOME to save $0, $2, $3, $4 ~ On the kernel stack/user stack (depending on the current mode ~ $7, $8 ~ $9 (64bit), $25, $28, $29, $31, STATUS, CAUSE, and EPC.

Save the context of the running task in switch_to:

Save STATUS and save $16 ~ with cpu_save_nonscratch ~ $23, $29 (sp), $30, and $31. If FPU is available, the fpu_save_double must be used to store the FPU register. All are saved in the thread_struct structure, which is part of task_struct.

These Save the context before and after switch_to.

Then load the context of the task to be run:
$28 <---- & thread_info
Cpu_restore_nonscratch recovery $16 ~ $23, $29 (sp), $30
* (Kernelsp) <---- & thread_info + THREAD_SIZE-32

Restore the STATUS (bit 0, bit 8 ~) saved in thread_struct ~ 15. Replace the current STATUS value)

At the time of restoration, switch_to and switch_to were replaced. All the operations were completed by switch_to calling the leaf function resume.

After do_IRQ is returned, the sp is restored (minus, symmetric addition, so it is irrelevant to the initial value and eventually points to the pt_regs structure of the new process) ref_from_irq is returned when the clock is interrupted (the environment in which the clock is interrupted at the time), and eret jumps back to the user State (or the core State interrupted by the clock) to continue running.

4. Why does switch_to not need to be saved $0 ~ $15 $24 ~ $27 (MIPS)
If the kernel needs to switch from process A to process B, the process is like this:

Process A --> clock interruption --> schedule --> switch_to (resume) --> schedule return --> ret_from_irq --> process B

The status of switch_to stored in A task_struct-> thread_struct is the processor status near the switch_to macro in the call chain.

Therefore, when you direct the sp to the sp stored in B task_struct-> thread_struct, it is actually equivalent to restoring process B to the status before and after switch_to:

Process B --> clock interruption --> schedule --> switch_to

Switch_to is a macro called. It is a leaf function located in arch/mips/kernel/r4k_switch.S (do not change the value of static registers, do not press the stack or exit the stack) resume, therefore, before entering resume, some non-static register values specified by ABI will no longer be used, so these non-static values do not need to be saved.

As for the value of the static register, the function will be stored on the stack before it is used. After it is restored, the value of the sub-function call will not change. Therefore, static registers are saved as part of the current running status. In this case:

In schedule, the compiler uses s0 to save an important state variable. Therefore, when schedule is started, the value of s0 is saved and s0 is used for calculation. After switch_to, further actions are determined based on s0.

At this time, s0 will be restored to the value of process B at this point. Note that after switch_to, all operations continue with process B:

Schedule returns --> ret_from_irq --> process B

5. sleep problems during interrupt handling
In Linux, you cannot sleep during interrupt processing. There are many protection measures in this kernel. Once the kernel is detected, exceptions may occur.

When A process A is interrupted because of the interruption, the interrupt handler uses the kernel stack of A to save the context, because it is the CPU Of, and the kernel stack of A is used, so the interruption should end as soon as possible. If do_IRQ is interrupted by the clock, the interrupt context is saved on the kernel stack of A. If scheduling occurs, schedule is added to switch_to, the interrupt context is saved in task_struct-> thread_struct of.

If it is interrupted by A clock during sleep and schedule is used, if process A is selected and switch_to is used, the returned result is in the state of the original sleep interrupted, aside from disrupting the operation of process A, the question here is: How can we wake it up?

In addition, the interruption that shares the interrupt number with the interrupt will also be affected.