What memory "state" does the kernel have to save between context switches?

2
votes

I'm currently reading How Linux Works: What Every Superuser Should Know, and I read the following about context switching:

  1. The CPU (the actual hardware) interrupts the current process based on an internal tinier, switches into kernel mode, and hands control back to the kernel.
  2. The kernel records the current state of the CPU and memory, which will be essential to resuming the process that was just interrupted.
  3. The kernel performs any tasks that might have come up during the preceding time slice (such as collecting data from input and output, or I/O, operations).
  4. The kernel is now ready to let another process run. The kernel analyzes the list of processes that are ready to run and chooses one.
  5. The kernel prepares the memory for this new process, and then prepares the CPU.
  6. The kernel tells the CPU how long the time slice for the new process will last.
  7. The kernel switches the CPU into user mode and hands control of the CPU to the process.

I understand what needs to be saved from the CPU's state (register values, etc...), but I don't understand what memory needs to be managed. Doesn't the process have its own block of memory, which should be unaffected by the context switch?

What about memory does the kernel need to save between context switches?

1
linuxmemory-managementlinux-kernel
I think it's just plain incorrect. On a task switch the kernel records the state of the CPU (in terms of processor registers and flags). The memory of the process doesn't need to be saved as such, because it is separate from the memory allocated to other processes anyway. Perhaps it's talking about the memory mapping (i.e. the active logical to physical address mapping). – davmac
Also step 6 seems like baloney: the kernel doesn't need to tell the CPU how long a time slice will last; rather, it uses a timer (which may or may not be part of the CPU) to generate an interrupt periodically, and that determines how long the time slice will last. Likewise in step 1, the timer (written tinier in your post) need not be part of the CPU. – davmac

1 Answers

6
votes

On a processor with a memory management unit (MMU) the main thing that occurs during a task switch with regards to memory is to tell the MMU to use a different virtual address space. This is assuming the destination task has a different address space, i.e. the task is a different process instead of a different thread in the same process. For example on 32bit x86, control register 3 (CR3) contains the physical address of the page directory table. During a task switch to a different process the appropriate CR3 value for the destination process is loaded into CR3 so all further virtual memory accesses use the new address space.

Memory itself is typically not saved in any manner as the MMU is used to protect pages so that one process cannot in general access another process memory. I say in general because there are a few cases where this is allowed but it is not relevant for this question.

In a memory constrained system, pages of memory can be stored to secondary storage (e.g. a hard drive) when there is a need for more virtual memory and there is no more free physical memory but this is usually not done during the context switch (although it could) and instead done on a demand basis. In either way storing memory to secondary storage is not an essential part of the context switch.

So in conclusion with regards to the following statement

The kernel records the current state of the CPU and memory, which will be essential to resuming the process that was just interrupted.

If by "memory" the statement is referring to the MMU state that controls the virtual to physical address translation then yes during a context switch this could be saved. I say could be because usually the CR3 value for a process does not change so there is no reason to save it as it is already known. If the statement is referring to the actual memory being used by the task then it is wrong.

And finally with regards to the following statement:

The kernel prepares the memory for this new process, and then prepares the CPU.

Again if by "prepares the memory for the new process" it means sets up the MMU to use the new virtual to physical address translation then yes that does happen during a context switch. If it means its loading memory from somewhere for the new process this does not need to happen, thanks to the MMU.