Linux Context Switching Analysis Notes (MIPS) __linux

1. Kernel stack Switching (MIPS)

When a dispatch switches to a process, the *KERNELSP is set based on the value of the task_struct->thread_info (the bottom of the kernel stack of the process currently running), and the value is Thread_info + thread_size-32 (MIPS, using SET_SAVED_SP macros).


2. Exception, interrupt register Save (MIPS)

When using Save_some to save the context, such as discovering a kernel mentality from a user state, first place the *KERNELSP into the SP using the GET_SAVED_SP macro. The Pt_size (=sizeof (struct pt_regs) size space is then allocated on the kernel stack as a storage space for the context. Save all the data carefully organized, and finally a struct pt_regs structure.

If the user state--> kernel state, then K0 = sp, sp = *kernelsp-pt_size,store K0, pt_r29 (SP), save other registers.

If the kernel state--> the kernel state, direct 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 on the kernel stack/user stack (depending on the mode at that time) to save $, $, $, $4~$7, $8~$9 (64bit), $, $28, $29, $31, STATUS, cause, EPC.

The context in which the task is running is saved in switch_to:

Save STATUS, use Cpu_save_nonscratch to save $16~$23, $29 (SP), $, and $31, with FPU and fpu_save_double to save the FPU registers. All are stored in the THREAD_STRUCT structure, which is part of the task_struct.

These are stored in the context before and after the switch_to.


Then load the task context that will be run:

$28 <----&thread_info
Cpu_restore_nonscratch restore $16~$23, $29 (SP), $
* (KERNELSP) <----&thread_info + thread_size-32
Restores the status saved in Thread_struct (bit 0, bit 8~15 replaces with current STATUS value)

Now recovery is also in the switch_to before and after the replacement of the unknown, all operations are by switch_to call the leaf function resume completion.

After the DO_IRQ returns, the SP recovers (minus how much, symmetrical plus how much, so it doesn't matter with the initial value, eventually points to the pt_regs structure of the new process) REF_FROM_IRQ then the clock breaks back (the environment when it was interrupted), and then Eret Jump back to the user state (or the core state of the clock interruption) to continue running.


4. Why switch_to do not need to save $0~$15 $24~$27 (MIPS)

If the kernel wants to switch from process A to process B, the process is probably like this:

Process a--> clock interrupt--> schedule--> switch_to (resume)--> schedule return--> RET_FROM_IRQ process B

Switch_to saved in a task_struct->thread_struct state is the processor state near the SWITCH_TO macro in the entire call chain

When you point an SP to an SP that is saved in B task_struct->thread_struct, it is actually the same as restoring to the state of process B before and after switch_to:

Process b--> Clock interrupt--> schedule--> switch_to

Switch_to is a macro, which is called, located in Arch/mips/kernel/r4k_switch. S in a leaf function (do not change the value of static registers, do not press stack, out of the stack) resume, so before entering the resume, the ABI specified some of the Non-static register value is no longer, so these non-static values do not need to save.

As for the value of the static register, the function is stored on the stack before it is finally restored, and the child function call does not change its value. So the static registers are saved as part of the state of the operation at that time. In this case:

Schedule compiler used S0 to save an important state variable, so enter the schedule first to save the S0 value, use S0 to participate in the operation, Switch_to, but also according to S0 judge further action.

This is the time to restore S0 to the value of process B at that point. All in all, note that all operations continue with process B after switch_to:

Schedule return--> RET_FROM_IRQ--> process B


5. Sleep problems during interrupt processing

Linux design, interrupt processing can not sleep, this kernel has a lot of protection measures, once the kernel will be detected abnormal.

When a process A is interrupted by interrupts, the interrupt handler uses the kernel stack of a to save the context, because it is the CPU of the "grab" A and the kernel stack of a, so the interrupt should end as fast as possible. If the DO_IRQ is interrupted by a clock interrupt, continue to save the interrupt context on the kernel stack of a and, if a schedule occurs, schedule into switch_to and save the context of the time interruption in the task_struct->thread_struct of a.

If it is interrupted by a clock interruption during sleep, and schedule words, if selected process a, and switch_to in the past, after the clock interrupt return is located in the original interrupted sleep state, put aside its disrupt the process of its unrelated to the operation not to say, the question here is: How to wake it?

In addition, interruptions to the interrupt sharing interrupt number are also affected.