What to do the processor when there is nothing to do?

It would be reasonable to assume that it would be quite easy for the kernel to do nothing — but it is not. At the 2018 Kernel Recipes conference, Rafael Vysotsky talked about what processors are doing, when they have nothing to do, how it processes the core, what current strategies have problems, and how his recent work on the inactivity cycle improved the situation with power consumption of systems that do nothing .

The idle cycle, one of the kernel subsystems that Vysotsky supports, controls what the CPU does when it doesn't need to run any processes. Vysotsky gave all the definitions very precisely: CPU is an entity that can receive instructions from the memory and execute them simultaneously with other entities in the same system that deal with the same. On the simplest single-processor system with a single core, this core is the CPU. If the processor has several cores, then each of these cores is a CPU. If each of the cores has several interfaces for the simultaneous execution of instructions - Intel calls such a system " hyperthreading " - then each of these threads will be a CPU.

The CPU stays idle when it has no tasks to perform. Or, more precisely, the Linux kernel has several internal dispatch classes, one of which is a special idle class. If there are no tasks on this CPU in any of the classes, excluding the inactivity class, then the CPU is considered inactive. If the hardware does not allow this, then the CPU will have to carry out useless instructions until the real work is done. However, this is an extremely inefficient use of electricity, so most processors support several low-power states, into which the core translates them until they are required to do useful work.

In the state of inaction can not just enter or exit. It takes time to enter and exit, and in addition, when you enter this state, the power consumption of the current state slightly increases, and when you exit it, the power consumption of the state into which the processor goes. And although the deeper the inactivity state, the less energy the processor consumes, the cost of entering and exiting to such states increases. This means that in the case of short periods of inactivity, the best use of computer resources will be shallow inaction; for longer periods, the cost of going into a deeper state of inaction will be justified by an increase in the amount of energy saved. Therefore, it is in the interests of the kernel to predict how long the processor will be idle before deciding how deep the inactivity state is needed.

In this cycle, the scheduler notices that the CPU is inactive, since it has no tasks to assign to it. Then the scheduler calls the regulator, which tries to give the best prediction of a suitable inaction state that you can enter. Now in the core there are two regulators, menu and ladder. They are used in different cases, but both are trying to do about the same thing: to monitor the state of the system when the CPU goes into inactivity state and the time it spent inactive. This is done in order to predict how long the CPU goes into a state of inactivity in it, and, therefore, which state is best suited for this situation.

This job is especially complicated by the CPU scheduler timer. The scheduler starts this timer to divide the access time to the CPU: if you need to perform several tasks on one processor, each of them can be performed only slightly, and then periodically set aside in favor of another task. This timer does not need to be performed on an idle CPU, since there are no tasks between which the CPU needs to be divided. Moreover, if you allow the timer to run on an idle CPU, it will not allow the controller to select deep idle states, limiting the intervals during which the CPU is idle. Therefore, in kernels up to 4.16, the scheduler turned off the timer before calling the controller. When the CPU was awakened by an interrupt, the scheduler decided whether there were any necessary tasks to complete the task, and if there were any, restarted the timer.

If the regulator predicts a long idle period, and this period really turns out to be long, then the regulator “wins”: the CPU goes into a state of deep inactivity, and energy is saved. But if the regulator predicts a long idle period, and this period turns out to be short, then the regulator “loses”, since the cost of entering a deep inaction does not pay off by saving energy in a short period of inactivity. Even worse, when the regulator predicts a short period of inactivity - then it “loses” regardless of the duration of the downtime: if the period was long, he missed the opportunity to save, and if short, then the costs of stopping and restarting the timer were wasted. Or, in other words, since resources are spent on stopping and starting the timer, it makes no sense to stop it,

Vysotsky decided to try changing the regulator's work, but he came to the conclusion that the main problem is that the timer is stopped before the regulator is called, that is, before the recommended idle state becomes known. He returned the inactivity cycle in kernel 4.17 so that the decision to stop the timer was made after the regulator issued its recommendation. If he predicted a long simple, the timer stops so as not to wake the CPU ahead of time. If the idle time is assumed to be short, the timer is left so as not to waste resources on outages. And this means that the timer also performs the security function, waking up the CPU if it turned out to be simple longer than predicted, and giving the regulator a second chance for the right decision.

When an idle CPU wakes up through an interrupt, whether it is a non-stopped timer or another event, the scheduler will immediately decide whether it is working. If there is work, the timer is restarted if necessary. If not, the controller is called. Since this means that the controller can now be called and when the timer is running, and when it is not working, the controller must be called to take this into account.

After examining the table of winnings and losses, Vysotsky believes that the changes he made will improve the picture. In the case of the prediction of a long inactivity, the timer still stops, so nothing changes here; we win, if the idle period is long, and lose, if short. But if a short period of downtime is predicted, we win: if the period turns out to be short, we will save on stopping and starting the timer, and if it is long, the non-stopped timer will wake us up and make it possible to make another prediction.


Since game theory cannot serve as a full-fledged replacement for the real situation, Vysotsky tested this approach on a variety of systems. The graph above is typical for all tested systems; it shows the dependence of energy consumption on the time of an inactive system. The green line is the old inactivity cycle, the red is the new one. Under the new scheme of energy consumed less, in addition, it is more predictable. Not all tested CPUs had such a big gap between the lines, but they all showed a flat red line under uneven green. As Vysotsky said, this new scheme less often predicts short periods of inactivity, but more often it turns out to be right about their short duration.

Answering a question from the audience, Vysotsky said that this work depends on the architecture. In particular, it will benefit from Intel processors, since they have a sufficiently large array of inactivity states, from which the controller can choose the one that is needed, which will give it the best chance of success in the case of a correct prediction; but ARM processors will also benefit from the new circuit.


A 20% drop in power consumption in a state of inactivity may seem like a minor achievement, but in reality this is not the case. Any system that wants to cope well enough with peak loads should have a power reserve in normal mode, which will manifest itself during inactivity. The graph above shows the processor usage for the year on my server, which handles mail, file transfer, VPN, NTP, etc. Yellow color means simple time. Saving 20% ​​of this energy would have pleased my provider, and for the planet it would be better.