From Mauerer's Linux Kernel Architecture,
Kernel threads are processes started directly by the kernel itself.
They delegate a kernel function to a separate process and execute it
there in ‘‘parallel‘‘ to the other processes in the system (and, in
fact, in parallel to execution of the kernel itself). Kernel threads
are often referred to as (kernel) daemons. They are used to
perform, for example, the following tasks:
- To periodically synchronize modified memory pages with the block device from which the pages originate (e.g., files mapped using mmap
).- To write memory pages into the swap area if they are seldom used.
- To manage deferred actions.
- To implement transaction journals for filesystems.
Basically, there are two types of kernel thread:
- Type 1 — The thread is started and waits until requested by the kernel to perform a specific action.
- Type 2 — Once started, the thread runs at periodic intervals, checks the utilization of a specific resource, and takes action when
utilization exceeds or falls below a set limit value. The kernel uses
this type of thread for continuous monitoring tasks.
-
Since Mauerer's book says kernel threads are processes, I think that
they must be running in user mode, instead of kernel mode. (or am I wrong? Can a process run in either user mode or kernel mode at different times, or only one mode?)But Bovet's Understanding Linux Kernel says kernel threads are
running only in kernel mode (see the quote below). Are the concepts
of "kernel thread" in the two books the same concept?Traditional Unix systems delegate some critical tasks to
intermittently running processes, including flushing disk caches,
swapping out unused pages, servicing network connections, and so on.
Indeed, it is not efficient to perform these tasks in strict linear
fashion; both their functions and the end user processes get better
response if they are scheduled in the background. Because some of the
system processes run only in Kernel Mode, modern operating systems
delegate their functions to kernel threads, which are not encumbered
with the unnecessary User Mode context. In Linux, kernel threads
differ from regular processes in the following ways:- Kernel threads run only in Kernel Mode, while regular processes run alterna- tively in Kernel Mode and in User Mode.
- Because kernel threads run only in Kernel Mode, they use only linear addresses greater than PAGE_OFFSET . Regular processes, on
the other
hand, use all four gigabytes of linear addresses, in either User Mode
or Kernel Mode.
-
Mauerer's book says kernel threads are started directly by the
kernel, and it seems to also say that daemons are synonyms of
kernel threads. So I think daemons must be started directly by the
kernel.But https://unix.stackexchange.com/a/193918/674 says that
screen's
daemon is started byscreenuser interface (see the quote below).
I thinkscreenuser interface is a process, instead of the kernel.
Are the concepts ofdaemonin Mauerer's book and in the linked
reply the same concept?When you first start
screen, you are actually starting a user interface (ui), which by default will create a daemon (the session
manager). -
In general, How do you understand the concepts of "kernel threads", "process", and "daemon", their relations and their differences?
Best Answer
First : Credit goes https://stackoverflow.com/questions/15983872/difference-between-user-level-and-kernel-supported-threads
User threads and Kernel threads are exactly the same. (You can see by looking in /proc/ and see that the kernel threads are there too.)
A User thread is one that executes user-space code. But it can call into kernel space at any time. It's still considered a "User" thread, even though it's executing kernel code at elevated security levels.
A Kernel thread is one that only runs kernel code and isn't associated with a user-space process. These are like "UNIX daemons", except they are kernel-only daemons. So you could say that the kernel is a multi-threaded program. For example, there is a kernel thread for swap. This forces all swap issues to get "serialized" into a single stream.
If a user thread needs something, it will call into the kernel, which marks that thread as sleeping. Later, the swap thread finds the data, so it marks the user thread as runnable. Later still, the "user thread" returns from the kernel back to userland as if nothing happened.
In fact, all threads start off in kernel space, because the clone() operation happens in kernel space. (And there's lots of kernel accounting to do before you can 'return' to a new process in user space.)