Shulou(Shulou.com)06/01 Report--

This article introduces the relevant knowledge of "what is the principle of linux process D state". In the operation process of actual cases, many people will encounter such difficulties. Next, let Xiaobian lead you to learn how to deal with these situations! I hope you can read carefully and learn something!

simply put

1) The kernel will accept requests from all processes at regular intervals (this may be related to CPU time slices and needs further confirmation). If a process is found to have initiated a request, the kernel will first obtain the resources needed by the process, and then temporarily put the process into a parking queue; this is similar to the requirements collection phase.

2) At the end of requirements collection, the process that initiated the request will be placed in a runnable queue for execution.

3) Execute the processes in the runnable queue in turn.

The D state of the process (Uninterruptible Sleep) occurs during the requirements gathering phase. Imagine at this stage, when the kernel to obtain the resources needed by the process, such as reading a file from disk, this time suddenly disk driver does not work (may be because too much data drive did not respond, may also be because of disk failure), this time the kernel is difficult, the scene becomes more awkward.

1) First, the driver is working in the kernel state, and the internal check driver has absolute trust; second,

2) The process initiated the request, and he, as the boss, should agree to it in both emotion and reason;

3) But what if the data requested by the process is not available?

4) At this time, the kernel can only temporarily convert the state of the process to the D state, indicating that the pot is the kernel's own, the kernel is trying to obtain the resources needed by the process, and the way to obtain the resources is controlled by the kernel (the kernel must have control over the global resources, otherwise it is not the kernel).

In the above case, if the data needed by the process is quickly obtained by the kernel (which is fine in most cases), the process will go from D state to a runnable state; if it is not (such as a real disk failure that the driver code does not consider, or the driver throws a signal but the kernel does not recognize), the corresponding process will remain in D state. Very dramatically, it's only operational Runnable processes can accept termination signals (kill signal), a process in state D has no way to be killed; This also complicates the process of terminating the D state-you have to restart the server to kill the D state process... but it's easy to understand, because the process is stuck in the kernel, and at this time the kernel and the process are bound, and it's natural for the kernel to restrict the process from accepting the kill signal.(My understanding is that the kernel here is overconfident, my fault machine is the 4.4.0 kernel version, maybe the later version has no such problem).

Reference:

https://jingwei.link/2018/12/23/linux-cpu-load-d-process.html

"What is the principle of linux process D state" is introduced here, thank you for reading. If you want to know more about industry-related knowledge, you can pay attention to the website. Xiaobian will output more high-quality practical articles for everyone!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.