Userspace process preempts kernel thread?

6
votes

Currently I am reading "Understanding the Linux kernel, 3rd edition" and on p.22 I can read:

In the simplest case, the CPU executes a kernel control path sequentially from the first instruction to the last. When one of the following events occurs, however, the CPU interleaves the kernel control paths:

  • A process executing in User Mode invokes a system call, and the corresponding kernel control path verifies that the request cannot be satisfied immediately; it then invokes the scheduler to select a new process to run. As a result, a process switch occurs. The first kernel control path is left unfinished, and the CPU resumes the execution of some other kernel control path. In this case, the two control paths are executed on behalf of two different processes.

The kernel control path can be interrupted from a user space process doing a system call? I thought the priority was pretty much:

  • interrupts
  • kernel threads
  • user space processes

I have checked the errata and could not find anything about this.

1
clinux
Thanks Jonathan for editing. This is new stuff for me. – ola1olsson
NP: there is help available while you're typing a question, but it takes a little experience to do it automatically. After you've been here a few years (actually, a month or so is probably sufficient), you'll be formatting it without thinking too hard. – Jonathan Leffler

1 Answers

4
votes

You are right about the priority list, but what (I think) the book is trying to say is:

  • When a (user) process makes a system call, the kernel starts executing on its behalf.
  • If the system call can be completed (the kernel control path does not run into a roadblock), then it will usually return direct to the calling process - think getpid() function call.
  • On the other hand, if the system call cannot be completed (for example, because the disk system must read a block into the kernel buffer pool before its data can be returned to the calling process), then the scheduler is used to select a new process to run - preempting the (kernel thread of control that was running on behalf of the) user process.
  • In due course, the original system call will be able to continue, and the original (kernel thread of control that was running on behalf of the) user process will be able to continue and eventually complete, returning control to the user space process running in user space and not in the kernel.

So "No": it is not the case that the 'kernel path can be interrupted from a user space process doing a system call'.

The kernel path can be interrupted while it is executing a system call on behalf of a user space process because: an interrupt occurs, or the kernel path must wait for a resource to become available, or ...