Recently, a timestamp system was written to record some important time nodes of each module in the system. Getting the kernel escalation timestamp is through the process polling, but found that the process in the actual running CPU utilization is very high, which is a dead loop in reading the device files, this thought is due to read system calls too frequent reasons.
Then write a test program, which is just an empty loop. It turns out that the CPU usage of the program is more than 90%!
I have 2 questions about this question, and I would like to share with you the understanding of these questions.
1 Linux system is a time-slice scheduling algorithm, all of the micro-operational processes are serial, regardless of what happens in the process, the process of time slices to switch to the next process, then why an empty loop process CPU utilization is so high.
To fully understand this problem, you need to figure out 2 questions.
(1) Several states of the Linux process and their switching relationships.
(2) How the CPU occupancy rate is calculated.
Several states of the Linux process and their switching relationships are described in more detail in the Deep learning Linux kernel, which is briefly explained here.
A process is a dynamic entity, so he is alive. From creation to extinction, is the entire life cycle of a process. During this cycle, the process may go through a variety of different states. In general, all processes undergo the following 3 states:
Ready state. means that the process has obtained all the additional resources needed to process the processor resources and is ready to begin execution. In this case, the process is said to be in the ready state.
Blocking states. Refers to a process that discards a processor because it needs to wait for the required resources (such as system call blocking or sleep), or the process does not own the processor, and other resources are not satisfied, even if the processor does not start running. In this case, the process is in a blocking state. The blocking state is also called a sleep state or a wait state.
Operating state. The process gets the processor, does not need to wait for any other resources, is executing the state, called the run-state. A process can use the requested resource only if it is in a running state. Only one process is in the running state at the same time in all processes.
In a Linux system, the various states have been re-organized, resulting in several states of the Linux process:
RUNNING: A process that is running or waiting to be run in the ready queue. This is the synthesis of the running state and the ready state process mentioned above. A process in the running state does not necessarily mean that he is being executed. Because in a multitasking system, each ready process requires concurrent execution, at some point in the running state, only one can get the processor, while the other processes must wait in a ready queue. Even in multiprocessor systems, Linux can only allow one processor to perform tasks at the same time.
Uninterruptable: Non-interruptible blocking state. A process in this state is waiting on the queue and can be woken up by the operating system when the resource is valid, otherwise it will remain in the waiting state.
Interruptable: interruptible blocking status. As with non-interruptible blocking states, processes in this state are in the waiting queue and can have an operating system wake up when the resource is valid. Unlike non-interruptible blocking states, a process in this state can also be awakened by signals from other processes.
STOPPED: Pending state. The process is paused and requires a signal from another process to be awakened. There are two causes for this state. One is the response to the signal (Sigstop,sigstp,sigttin or Sigttou). The second is controlled by the ptrace call of the parent process, and the processor is temporarily handed over to the control process.
ZOMBIE: Zombie status. A state that represents the end of a process but not yet extinct. At this point the process has finished running and freed most of the resources, but the process control block has not been released.
When you view a process using the PS command, you can see that the "S" process refers to a blocked state, and the "R" process is in the ready or running state. The
further understands that Linux is a process scheduler that allocates time slices to the processes in the ready queue. The blocked and suspended processes are in the blocking queue, and only wake up to wait for the kernel to be dispatched in the ready queue.
Then look at how CPU occupancy is calculated.
The first thing to understand is that as long as the device on the CPU will not idle, there will always be a process to occupy the CPU run, the Linux kernel boot will eventually start the cpu_idle process, the process will be dead loop call schedule function to dispatch, even if there is no process in the ready queue can be scheduled, That is, there is no process when the running state, the CPU will continue to die in the Cpu_idle cycle. And what we used to say about CPU occupancy is that there are processes in the ready queue that are scheduled to use the CPU,CPU share, which is a percentage of the CPU that the process uses.
Figure out the above two points, and then look at our problems in turn. Why is the CPU usage of the empty loop process high?
As you can imagine, although nothing is done in the empty loop process, there is no blocking condition (such as sleep), the process is in the running state, that is, even if the process time slice is switched, the process is in the ready queue, waiting for the next dispatch.
The Linux kernel scheduling algorithm is very complex, it is understood that in addition to the time slice there will be a priority bonus, for the process has been in the ready queue priority will also improve.
Here we go to simplify, assuming that the Linux kernel scheduling algorithm is only time-slice scheduling, that is, all the running process time slices in 1s is equal, in fact, the 1s time is divided into the ready queue of all processes. So the point of the question is how many processes in the readiness queue will divide the time.
The PS command on my device looks at the status of the process and discovers that only the empty loop process is in the running state.
But because top is also a running process when running the top command, the Linux kernel at this point only dispatches the 2 processes back and forth, and of course the CPU usage of the empty loop process is high!
2 Since the CPU is always occupied, how the CPU load is interpreted, how the empty loop process affects the system.
To understand the problem of the empty loop process, I have a question about the CPU load, since the CPU has always been a process occupation, that is, the CPU is actually full load, why there is the high level of this said.
My understanding is that, for the CPU, it has been in accordance with the fixed frequency command to run, no load level of said, we say that the load is actually a human sense of the statement, such as top view found high CPU utilization, system main application process (such as SH) slow reaction, we say the load is high.
For example, the CPU can be likened to a home robot that can cook and wash clothes and sweep the floor, and the speed at which the robot does the work is constant. Cooking is done in 10 minutes, but if it is required to cook and wash the clothes and sweep the floor at the same time, standing on the robot's point of view, no difference, the speed is the same. But from our point of view our main application-cooking, we find that it is slow to cook, we think the robot is not too high load.
As a result, the effect of an empty loop on the system is understood, resulting in a more meaningless process in the ready queue, but an empty loop process is less noticeable.
There are only 2 processes in the ready queue, the main application process can run 0.5s within 1s, but if there are 20 processes, only 0.05s can be run, and the execution response efficiency of the process is down.
This can be done in a simple experiment, in my device system to start dozens of empty loop process, found that the system console reaction is slow, which validates the above statement.
Why is the empty loop process causing high CPU occupancy?