Process Management in Linux Kernel

0
votes

I have been studying the subsystems of the Linux kernel. There, it is written that Linux kernel is responsible for context switching(letting another process to use the CPU). Here are the steps the kernel goes through to do context switching:

  1. The CPU (the actual hardware) interrupts the current process based on an internal timer, 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.

Problem with me is that I can't understand the 3rd step above. Can someone please shed some light on that sentence? Thanks!

1
linuxlinux-kerneloperating-systemmultitasking
User mode / kernel mode (supervisor mode) are not turned off/on by kernel rather determined by flags in page table entry. (search for user/supervisor bit). Regarding the 3rd bullet, what don't you understand? – Tony Tannous
What kind of tasks can be left for kernel to performed later? This question arises from the sentence "The kernel performs any tasks that might have come up during the preceding time slice". – Meylis
Each interrupt has it's own handle, but a simple example would be to copy a packet from kernel space buffer to user space buffers when recieving data. Doesn't have to be on timer interrupts – Tony Tannous

1 Answers

0
votes
  1. The CPU (the actual hardware) interrupts the current process based on an internal timer, switches into kernel mode, and hands control back to the kernel.

Most task switches are caused by tasks blocking (because they have to wait for a mutex, disk IO, user IO, end-user action, etc).

It's better (more accurate) to say that "something" (IRQ, system call) causes a switch to the kernel's code before the kernel decides it wants to do a task switch, and that this "something" is not part of the task switch itself.

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

Sort of. Because "something" (IRQ, system call) causes a switch to the kernel's code before the kernel decides it wants to do a task switch; all task switches only every happen between kernel's code (for one task) and kernel's code (for another task). Because task switches only ever switch from kernel's code to kernel's code; the task switch itself doesn't need to care about user-space memory (which isn't so important for kernel's code) or kernel's memory (which is global/shared by all CPUs and all virtual address spaces). More; because some registers are "callee preserved" (by C calling conventions) and some are "constant as far as kernel is concerned" (e.g. segment registers) the task switch code doesn't need to care about various parts of the CPU state either.

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

Also not part of the task switch (more "things that happen before or after kernel decides to do a task switch").

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

Sort of; but it's no as simple as a list, and sometimes (e.g. high-priority real time thread unblocks and preempts a less important task) the kernel knows which task it needs to switch to without doing anything extra.

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

For memory; kernel mostly just loads a new "reference for new task's virtual address space" (e.g. a single mov cr3, ... instruction on 80x86). For CPU state, it's the reverse of "2. The kernel records the current state of the CPU ..." above (loading what was previously saved, where some CPU state isn't loaded and isn't saved).

  1. The kernel tells the CPU how long the time slice for the new process will last.

Yes.

  1. The kernel switches the CPU into user mode and hands control of the CPU to the process.

Not really. It's better (more accurate) to say after the kernel has finished doing a task switch, the kernel code for the new task does whatever it wants (and eventually may return to user-space); and that "things that happen after task switch finished" are not part of the task switch.