Linux common processes and kernel threads

Kthreadd: This kernel thread has only one function, which is to manage the dispatch of other kernel threads. It is created when the kernel is initialized and loops through a function called Kthreadd, which is the function of running the Kthread maintained in the Kthread_create_list global list. You can call Kthread_create to create a kthread that will be added to the Kthread_create_list list while kthread_create weak up kthreadd_task. Kthreadd in execution Kthread will call the old interface--kernel_thread run a kernel thread called "Kthread" to run the Kthread created, the Kthread will be executed from Kthread_create_ The list list is deleted, and Kthreadd will constantly call scheduler to yield the CPU. This thread cannot be closed.

Migration: Each processor core corresponds to a migration kernel thread, the main function is as the corresponding CPU core migration process, used to perform process migration operations, the function in the kernel is Migration_thread (). A load-balancing system belonging to the 2.6 kernel that automatically loads (one per CPU) at system startup and sets itself as a real-time process for Sched_fifo, and then checks to see if there are requests waiting to be processed in runqueue::migration_queue, if not, Sleep in task_interruptible until it is awakened and then checked again. Migration_queue is only added in set_cpu_allowed (), when a process (such as shutting down a CPU via APM) calls set_cpu_allowed () to change the currently available CPU, so that a process is not suitable to continue running on the current CPU, A migration request data structure migration_req_t is constructed, it is implanted into the migration_queue of the CPU-ready queue of the process, and then the migration of the ready queue is awakened Daemon (recorded in the Runqueue::migration_ Thread attribute), migrate the process to the appropriate CPU in the current implementation, the purpose of the CPU selection and load-independent, but "Any_online_cpu (req->task->cpus_allowed)", that is, by the CPU Number sequence of the first allowed CPU. So, unlike Load_balance (), which is closely related to the scheduler and load Balancing strategy, Migration_thread () should be just one interface for CPU bindings and CPU power management functions. This thread is an important part of the dispatch system and cannot be closed.

Watchdog: Each processor core corresponds to a watchdog kernel thread, watchdog is used to monitor the operation of the system, automatically restarts the system in the event of a system failure, including a kernel watchdog module and a user space Watchdog program. Under the Linux kernel, the basic principle of watchdog is: When the watchdog is started (that is, after the/dev/watchdog device is opened), if in a set time interval (1 minutes)/dev/watchdog has not been performed the write operation, The hardware watchdog circuit or software timer restarts the system, and each write operation causes the timer to be reset. /dev/watchdog is a character device node with a master device number of 10, from device number 130. The Linux kernel not only provides drivers for a variety of different types of watchdog hardware circuitry, but also provides a pure software watchdog driver based on timers. If this failure-handling mechanism is not required, or if there is a corresponding alternative, you can use the Menuconfig
Device drivers->
Watchdog Timer Support
To cancel the watchdog function.

events: Each processor core corresponds to an events kernel thread. Many hardware and software events (such as power outages, file changes) that are used to handle kernel events are converted to events and distributed to the threads that are interested in the corresponding event response. Important thread to handle kernel events, cannot be removed

KBLOCKD: Each processor core corresponds to one KBLOCKD kernel thread. A block device used to manage a system that periodically activates block device drivers within the system. If you have a block device, then these threads cannot be removed, and if you want to remove it, you need to set the Config_block to n directly in the. config and cancel it in Menuconfig
Device drivers->
Block devices

khelper: This kernel thread has only one, the main role is to specify the user space of the program path and environment variables, the end of the run of the specified users of the program, the user space is a critical thread, cannot be closed

Pdflush:This kernel thread has a total of two, the thread name is Pdflush, the main function is to write back the dirty pages in memory, reclaim the space occupied by dirty pages. Because of the caching effect of the page cache, the write operation is actually delayed. When the data in the page cache is newer than the data stored in the background, the data is called dirty data. The dirty pages that accumulate in memory must eventually be written back. When the following two scenarios occur, the dirty pages are written back:
1. When free memory falls below a specific threshold, the kernel must write the dirty page back to disk to free up memory.
2. When a dirty page resides in memory for more than a certain threshold, the kernel must write the dirty page that is timed out back to disk to ensure that the dirty page does not reside in memory indefinitely.
For the first target, the Pdflush thread flushes the dirty page back to disk when free memory in the system falls below a specific threshold. The background writeback routine is designed to free up dirty pages to regain memory when available physical memory is too low. Specific memory thresholds can be set through the DIRTY_BACKGROUND_RATIOSYSCTL system call. When the free memory ratio threshold: dirty_ background_ratio is low, the kernel calls the function Wakeup_bdflush () to wake up a pdflush thread, and then the Pdflush thread calls the function further Background_writeout () to start writing dirty pages back to disk. The function Background_ writeout () requires a long integer parameter that specifies the number of pages to be written back. The function background_writeout () writes the data continuously until the following two conditions are met:
1. The specified minimum number of pages has been written out to disk.
2. The number of free memory has rebounded, exceeding the threshold dirty_background_ratio.
The above conditions ensure that the Pdflush operation can alleviate the low memory pressure in the system. The writeback operation does not stop until both conditions are reached, unless Pdflush writes back all the dirty pages, and no remaining dirty pages can be written back.
For the second target, the Pdflush background routine is periodically woken up (regardless of whether free memory is too low), writes out dirty pages that have been in memory for too long, ensuring that there are no persistent dirty pages in memory. If the system crashes and the memory is in disarray, the dirty pages that have not yet been written back to the disk in memory are lost, so it is important to periodically synchronize the page cache and disk. at system startup, the kernel Initializes a timer that periodically wakes up the pdflush thread and then makes it run function wb_kupdate (). This function will write back all dirty pages that have resided longer than dirty_expire_centisecs seconds. Then the timer will be initialized again to dirty_expire_ centisecs seconds after the wake Pdflush thread. All in all, the Pdflush thread is woken up periodically and writes dirty pages that are more than a certain period back to disk.
System administrators can set write-back related parameters in/proc/sys/vm, or they can be set by SYSCTL system calls.Cat/proc/sys/vm/dirty_background_ratio
Memory management thread that belongs to the core, and this thread cannot be shut down

kswapd0: This kernel thread has only one, and the main function is to reclaim memory. In KSWAPD, there are 2 thresholds, Pages_hige and Pages_low. When the number of free memory pages is less than Pages_low, the KSWAPD process scans the memory and releases 32 free pages at a time until the number of freepage reaches Pages_high. The following principles exist in the specific recycling:
1. If the page is not changed, put the page into an idle queue;
2. If the page has changed and can be backed back to the file system, understand that the contents of the memory page are written back to disk;
3. If the page has changed but does not have any backup on the disk, write it to the swap partition.
Similarly, a memory management thread that belongs to the core cannot be shut down

nfsiod: This kernel thread has only one, the main role is to provide NFS with an efficient buffering mechanism, thereby improving the performance of NFS file system, if you do not need NFS, you can cancel this thread, the method of canceling this thread is menuconfig cancel
File systems->
Network File Systems

Rpciod: Each processor core corresponds to a rpciod kernel thread, the main role is to serve as a daemon for the remote Procedure Call service, to start the I/O service from the client, usually to start the NFS service to use it, want to close it, you need to put the config in. config _sunrpc, CONFIG_SUNRPC_GSS, CONFIG_SUNRPC_XPRT_RDMA values are set to n

kpsmoused: This kernel thread has only one, the main function is to support the mouse driver of the PS/2 interface. To cancel without a mouse, the cancellation method is Menuconfig
Devicedrivers->
Input Device Support
Mice

What is process migration?
Process migration is the move of a process from its current location to the specified processor. Its basic idea is to move it during process execution so that it continues to access all of its resources on the other computer and continues to run, without knowing that the knowledge of the running process or any other interacting processes can initiate a process migration operation, which means that the migration is transparent.
Benefits of process migration
Process migration is a very effective means of supporting load balancing and high fault tolerance. A study of a series of load balancing strategies indicates that process migration is the basis for load balancing and that process migration is adaptable in many ways:

Dynamic load balancing: Migrate processes to lightly loaded or idle nodes, take advantage of available resources, and improve performance by reducing the difference in load between nodes.
Fault tolerance and high availability: In the event of a node failure, continuing to resume operations by migrating the process to another node will greatly improve the reliability and availability of the system. This is especially important in some critical applications.
Parallel file IO: Migrates the process to the file server for IO, rather than transferring the data to the process through the network through the traditional file server. For those processes that require a large amount of data to be requested from the file server, this will effectively reduce the amount of traffic and greatly improve efficiency.

Take advantage of special resources: processes can migrate to take advantage of unique hardware or software capabilities on a node.

Memory ushering mechanism: When a node runs out of its main memory, the memory ushering mechanism will allow the process to migrate to other nodes that have free memory, rather than having the node frequently paging or exchanging with external memory. This approach is suitable for systems where the load is balanced, but the memory usage is different or the physical configuration of the memory is different.
Implementation perspective of Process migration
The implementation complexity of process migrations and dependencies on the OS hinder the widespread use of process migrations, especially for transparent process migration implementations. Depending on the level of application, process migration can be part of the OS, a user space, a portion of the system environment, or become part of an application.

User-level migration: User-level implementation is relatively simple, software development and maintenance is easier, so many existing systems are implemented using user-level, such as Condor and Utopia. However, because all States of kernel are not available at the user level, migration is not possible for a class of processes. In addition, because of the barriers between the kernel space and the user space, it is costly to break this boundary to get the services provided by kernel. As a result, user-level implementations are much less efficient than kernel-level implementations.
Application-Level Migration: application-level migration is simple and portable, but requires an understanding of application semantics and may require modifications or recompilation of the application, with poor transparency, such as Freedman, Skordos, and so on.
Kernel-level migration: the kernel-based implementation can take full advantage of the functionality provided by the OS, fully capture process and OS state, and therefore achieve high efficiency and provide users with good transparency. However, due to the need to modify the OS, the implementation is more complex. Typical systems in this area are Mosix and sprite systems.

Process status
The main task of a process migration is to extract the process state and then regenerate the process at the destination node based on the process state. In reality, a process has a lot of state, and as the operating system evolves, the process state is more and more diverse. In general, the state of a process can be divided into the following categories:

Process Execution status (execution state): Represents the processor state of the currently running process, and is highly dependent on the machine. This includes information that the kernel saves and recovers during context switching, such as general and floating-point register values, stack pointers, condition codes, and so on.
Process Control: All the letters that the operating system uses to control the process, typically including process priorities, process identities, parent process identities, and so on. Once the process control information has been orchestrated, the process migration system must freeze the process's operation.
Process memory state and process address space: Includes all the virtual storage information of the process, process data and process stack information, etc., is the most important part of the process state.
Message state of the process: Contains control information for the process buffered message and connection (link). The maintenance of communication connections in process migration and the recovery of post-migration connections are a more challenging issue in process migration.
File Status: The file status of the process includes file descriptors and file buffers fast. Keeping cache consistency and inter-process file synchronization access to files is also a process migration mechanism that needs to be considered.
Because of the relatively easy extraction and recovery process state in homogeneous environments (identical or compatible machine architectures and instruction sets and operating systems), most of the existing work is premised on homogeneous environments. However, more and more people are beginning to study the process migration mechanism in heterogeneous environment, such as TUI System.

Linux common processes and kernel threads