I recently became the 'happy' owner of a netbook based on the Atom N270. Windows XP, of course for me, was immediately thrown from the hard disk and replaced with Linux. And everything was fine ... about 15 minutes, until the processor (in general, of course, everyone will tell you that it was not the processor, but the chipset, but all sorts of tests, like torsion of endless empty cycles in bash, showed that it was the processor) that was not overly hot during the installation of all sorts of different packages (I don’t understand at all where Intel got the estimate for TDP N270 at 2.5W)
Another situation. My friend has a rather old ASUS laptop with quite strange ACPI settings, the tables of which say that throttling should be enabled at a system temperature of 89 degrees Celsius, and the system should be cut off from critical overheating at a temperature of 81 degrees.
Ems ... You do not consider it all anti-PR ASUS and Intel, because (I am sure) on other laptops (no) beeches with other x86-processors there are quite similar problems, and this post is about how to solve them, and not about what ProAativativnye IT flagships ... In general, I'm a fan of ARMs ... So for me, that Intel, that AMD is the same x86-evil ... But just the fact remains. In some older models of laptops from ASUS, the curves are ACPI tables, and Atom's are heated.
')
It is necessary to somehow control the operating modes of the processor in order to cool down the fervor of hot silicon guys, so that they do not destroy the natural cool microclimate for the penguin.
The only problem is that the standard recipes for manipulating only the power levels of the processor in Linux (using the cpufreq subsystem), which are distributed to all forums right and left, are not effective enough. The same Atom significantly heats up being in the most "economical" mode, and my friend in the work periodically needs high processor performance, but not at the cost of shutdown at a critical temperature. And at the same time, resetting the processor of his laptop to the 'economical' mode did not save when the temperature rises from overheating.
In general, problems need to be solved somehow. Actually, somewhere for a threesome with a plus, they turned out to be resolved, I describe the solution below with some details that are rarely written on the Linux user-forums (and in general, I didn’t even understand where I got this solution from :).
So. First a bit of theory.
1. Modes of operation of the processor.
Any x86 processor respecting itself has a lot of modes. They are all described in a terribly voluminous document loudly referred to as the ACPI Specification. And briefly they can be described as follows.
CPU Modes These states are called CN, where N is a certain number from 0, 1, 2, 3 to the imagination of the developers of this processor. Opterons seem to be able to fall asleep in C8 mode as well.
C0 mode is the operating mode in which the processor executes instructions. And C1, ... - sleep modes. In these modes, the kernel of the operating system transfers the processor to those moments when it realizes that, in general, it does not have to execute any code (for example, all threads processes wait for some data to continue working, or the user himself instructs the system fall asleep). These modes differ in several parameters. The most important of them are:
(1) the time of entry and exit from this mode, latency, that is, the delay with which the processor will wake up when a significant hardware event occurs (for example, the appearance of an interrupt signal from a device);
(2) whether the processor continues to provide some functionality during sleep. For example, does it continue to ensure that the contents of its cache are consistent with the contents of the RAM.
The ACPI standard tells us: the greater the N in the CN, the greater the delays in entering / exiting to / from this mode, and the less functionality the processor supports.
Usually, in C1 mode, the processor falls asleep shallowly. This is a dream in which he falls on the execution of the instructions hlt. He falls asleep / wakes up quickly in this mode, and all his systems are active. In C2 mode, it falls asleep / wakes up more slowly, many subsystems in it are turned off, and in C3 mode, it ceases to track requests in RAM in order to reconcile the contents of its cache with memory.
Delays are important here so that the OS kernel can program timers correctly, so that the processor wakes up just at the end of the sleep interval requested by some processes: if the process requested sleep in one second, and the delay for entering and exiting the C2 state of the processor .1 second, the kernel should program a timer for the tick and interrupt generation after .9 seconds. A primitive example, but, I hope, quite illustrative.
During the system activity (habrachelovek sent his computer to suspend), the processor is sent to sleep at maximum in C2 mode (matching the caches is a serious thing). And it is transferred to the C3 state only when the user presses the sleep button or launches the command
pm-suspend
.
You can admire how your processor cores sleep.
$ cat / proc / acpi / processor / CPU0 / power
active state: C0
max_cstate: C8
maximum allowed latency: 16000 usec
states:
C1: type [C1] promotion [-] demotion [-] latency [000] usage [00000000] duration [00000000000000000000]
Naturally, CPU0 needs to be replaced with the number of the processor whose status you want to know.
OK.
Performance Modes When the processor is not sleeping (in C0 mode), it works (here it is, the ideal, the victorious laziness). But the processor can work with different power consumption and with different frequency. The lower the frequency, the less energy can be consumed, the less heat and in general, the least, including performance.
In general, here. There is nothing more to say. These modes are usually denoted PN, where N is from 0 to ... and the more N, the less frequency and power consumption. You can see the possible P-states like this:
$ cpufreq-info
cpufrequtils 006: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
driver: powernow-k8
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 8.0 us.
hardware limits: 800 MHz - 3.00 GHz
available frequency steps: 3.00 GHz, 2.30 GHz, 1.80 GHz, 800 MHz
available cpufreq governors: conservative, performance
current policy: frequency should be within 800 MHz and 3.00 GHz.
The governor of "conservative" may decide
within this range.
current CPU frequency is 800 MHz.
cpufreq stats: 3.00 GHz: 5.81%, 2.30 GHz: 3.70%, 1.80 GHz: 10.42%, 800 MHz: 80.07% (1425)
analyzing CPU 1:
driver: powernow-k8
CPUs which run at the same hardware frequency: 1
CPUs which need to have their frequency coordinated by software: 1
maximum transition latency: 8.0 us.
hardware limits: 800 MHz - 3.00 GHz
available frequency steps: 3.00 GHz, 2.30 GHz, 1.80 GHz, 800 MHz
available cpufreq governors: conservative, performance
current policy: frequency should be within 800 MHz and 3.00 GHz.
The governor of "conservative" may decide
within this range.
current CPU frequency is 800 MHz.
cpufreq stats: 3.00 GHz: 0.52%, 2.30 GHz: 1.21%, 1.80 GHz: 5.99%, 800 MHz: 92.28% (651)
In fact, the frequency of a modern processor can be varied more smoothly. For example, with the Athlon II X2, this one can be changed in 100MHz increments, but Linux shows here and uses the P-states described in the ACPI tables, that is, the points at which the core voltage also changes. Maybe this will be changed in future versions of the kernel.
But that is not all. Working in a certain performance mode, the processor can be in
the skip cycle — the T-state. Again, T0 mode means that the processor does not skip cycles, and T7 means that the processor uses only every 8 clock cycles of the clock generator for its operation.
It is clear that the more clock cycles the processor misses, the less it heats. Throttle modes appeared in the Pentium4 processor and were actively used there to prevent overheating of this overly hot engineering genius product (or insanity ... as you like more :) one replay system is worth something. Well, okay, then the past years).
You can look at possible T-states like this:
$ cat / proc / acpi / processor / CPU0 / throttling
not supported
2. Cpufreq.
If the kernel transfers the processor to the C1, C2, C3 modes quite independently, as soon as it finds in the ACPI tables a description of the processor's ability to make this transition (for this the processor.ko driver must be loaded), then to transfer the processor between the P-states it needs subsystem modules Cpufreq.
There are two main components here - drivers for processors that can recognize valid P-modes and drive the processor between them, and controllers. They are drivers in cpufreq drivers, but the managers are amusing little animals.
The manager is a kernel module that implements some policy of transferring the processor from one P-mode to another. For example, the manager powersave keeps the processor at the most economical P-mode possible (the minimum and maximum are limited by the hardware capabilities, the cpufreq settings and the interface restrictions). Or, for example, the manager ondemand, upon detecting that the processor load has reached a certain threshold (which can be set via settings), immediately sends it to the most productive of the allowed P-modes and keeps it there until the processor load drops below a certain threshold value (while this threshold cannot be changed, however, there is a more flexible manager conservative).
Here ... Here, too, probably nothing more to say. Is it only to report that the
cpufreq-info
utility provides all the statistics about which managers are available in the system, and what restrictions are set for frequencies, and what frequency is current. Etc. If some controllers are not available, it means that you have not loaded the appropriate kernel modules. You can correct the situation with a command like this:
modprobe cpufreq-conservative
. Or by inserting the appropriate modules in the startup list in your distribution.
You can manually switch between different processor modes by using the
cpufreq-set
utility. For example,
# cpufreq-set --min 800MHz --governor powersave
transfer the processor to
And for more information, anyone can look in the directory:
# ls / sys / devices / system / cpu / cpu0 / cpufreq / | cat
affected_cpus
conservative
cpuinfo_cur_freq
cpuinfo_max_freq
cpuinfo_min_freq
cpuinfo_transition_latency
related_cpus
scaling_available_frequencies
scaling_available_governors
scaling_cur_freq
scaling_driver
scaling_governor
scaling_max_freq
scaling_min_freq
scaling_setspeed
stats
3. Cpufreqd.
This amusing little animal can do this. It can track some system parameters, including those important for the problem being solved: (1) the temperature level in various temperature zones of the computer and (2) the CPU utilization level by calculations. And based on the received data, it can change the settings of the cpufreq subsystem in the kernel, or execute some command.
Cpufreqd is guided in its difficult life by the description of profiles and rules taken from the configuration file. Profiles are descriptions of some actions, for example: select the controlling powersave and set the minimum frequency to 30% of the maximum available, and execute the 'echo Hello World' command in the shell.
Rules are lists of conditions that cpufreqd periodically checks and evaluates, gives them points for compliance with the current situation, and then applies the rule that gets the highest rating. Rule execution is the execution of instructions in the profile associated with a rule.
Actually here. It's simple. And an action plan emerges: you need to configure cpufreqd so that when the temperature rises beyond a certain threshold, it switches the processor to the most economical of the P-states, and forces the CPU to save, save, and save again.
And at a normal temperature, he would keep the CPU with an ondemand policy, for example, so that there would be enough performance, and not everything would be heated very much when the system was idle.
4. Some lyrics.
Unfortunately, this trick does not work with Intel processors :(. It just got sore (how many I fought with my Atom and with a P3 friend), so I’ll write. For example, with the official 25 Watt Turion X2, I didn’t have any problems at all. I turned on managing the conservative for both the processor cores and working quietly for himself. Noticing the significant heating of the laptop only under really serious workloads like video encoding.
The manager conservative is similar to ondemand. Only it is smoother. When conservative detects that the computational load on the processor has increased over a certain period of observation to a certain threshold value (80% by default), it switches the processor to a more efficient P-mode. When he notices that it has fallen below another threshold (20%), then he puts the processor into a less productive P-mode. This is a simplified description, but generally adequate. So, it is very convenient and in the case of my Turion, everything worked fine.
But the Atom behaved much worse. Naturally, I tried to do the same trick with him. But Atom began to bask in even the most inefficient P-state. And then another friend appeared with his Dothan, with whom this conservative trick did not work either. The laptop overheated and cut down.
5. Let's throttle'it.
But let's not despair, and remember that the processors have another twist - T-states. And you can turn this twist through the so-called limit-interface. Although this is scaryly called, this is very simple: it is possible to limit the minimum by number, that is, P and T maximum states. If you look like this:
$ cat / proc / acpi / processor / CPU0 / limit
active limit: P0: T6
user limit: P0: T6
thermal limit: P0: T0
(this is a different processor, T2050)
then you can see that these are the very limitations. active is current, user is installed by the operating system, and thermal is the one that should install the BIOS or hardware when overheating is detected.
If through this limit-interface we set limits on T-states, then the processor will fall into throttle'ing and start to warm up significantly less. In the code above, my processor is in the T6 state because of its idleness, and this means that it only works for every 4th clock.
6. OK. All together or config for cpufreqd.
[General]
pidfile = / var / run / cpufreqd.pid
poll_interval = 0.5
[/ General]
[Profile]
name = idle
minfreq = 0%
maxfreq = 100%
policy = powersave
exec_post = echo -n 0: 6 | tee / proc / acpi / processor / CPU [01] / limit> / dev / null
[/ Profile]
[Profile]
name = basic
minfreq = 0%
maxfreq = 100%
policy = conservative
up_threshold = 75
down_threshold = 25
ignore_nice_load = 1
exec_post = echo -n 0: 0 | tee / proc / acpi / processor / CPU [01] / limit> / dev / null
[/ Profile]
[Profile]
name = too_hot
minfreq = 0%
maxfreq = 100%
policy = powersave
exec_post = echo -n 0: 7 | tee / proc / acpi / processor / CPU [01] / limit> / dev / null
[/ Profile]
[Rule]
name = idle
profile = idle
acpi_temperature = 0-55
cpu_interval = 0-6.25
[/ Rule]
[Rule]
name = basic
profile = basic
acpi_temperature = 0-55
cpu_interval = 75-100
[/ Rule]
[Rule]
name = too_hot
profile = too_hot
acpi_temperature = 55-100
[/ Rule]
Actually here. It's simple. The logic of this configuration file is as follows.
A. cpureqd polls system status every 0.5 seconds.
B. When a low computational activity is detected in the system, it goes into the least productive P-state and into a fairly deep throttle'ing (actually, it’s fan selected here, it’s more comfortable to work when polling takes place every 0.25 seconds and in idle state the processor goes in T4).
C. In load mode, the processor is controlled by the conservative policy with minimal restrictions. And with a little twisted thresholds to go through the performance mode up and down. Upwards the conservative will go when in the current state the CPU load exceeds 75%, and down when it falls below 25%.
D. When the temperature rises above 55 percent (yes, cpufreqd is strange) from the maximum, this will lead to the execution of the too_hot profile, which will take the processor to maximum throttling and minimum performance from the P-states.
A little trick here is to use the cpu_interval condition in the rules. The idle load is the load on the CPU from 0 to 6.5 percent for the previous monitoring interval. A basic load - load from 75 to 100.
The logic is as follows. If you remember, I wrote that cpufreqd in the course of its work analyzes the set of its rules and gives each assessment how much it corresponds to the current situation. And if the score of a rule is high enough and exceeds all high enough marks, then cpufreqd applies the profile that corresponds to this rule (profiles, in fact, but not important). Therefore, when cpufreqd sees that the processor load does not fall within the intervals [0, 6.25] or [75, 100], at the normal temperature of the system, it simply does nothing.
So here. We need to switch from the basic state to the idle state and back. When the processor is in the basic state due to conservative settings when loading less than 25%, it will transfer the processor to a lower (here and further in performance) P-state, thereby increasing the processor load in percentage terms by current calculations - just all tasks start to be performed slower, therefore, require more CPU time, therefore, the processor is loaded more.
But from the lowest P-state, the processor must jump to the idle state when it is 4 times slower than in the lowest P-state. And he should jump there with a sufficiently low load. I chose this option to be 25/4, but in fact it would be possible
choose any number less than, say, 60/4, so that when jumping in idle, the load on the processor does not increase enough to trigger the basic rule, which should work when the load is high (more than 75%) in the idle state. At the same time, 60/4 is still less than 25, so the idle mode will not turn on when working under the control conservative, which, when a processor load of less than 25 is detected, will switch it to a lower P mode, which will increase the processor load. And, therefore, the idle state will not turn on until the load on the processor starts to fall in the lowest P-mode. CTD.
Here it is. Everything is quite simple. Finally, I'll write that the parameters 0.5, 0: 6 and 6.25 are fan-made, and may not be comfortable when working in KDE or GNOME, changing the operating modes of the system every .5 seconds is noticeable to the user. Therefore, it is better to use the values 0.25, 0: 4, 12.5, respectively. In addition, of course, you will have to follow the temperature of your system and set the temperature intervals that are comfortable for you. Here it should only be remembered that there are a lot of thermal zones in the computer, and in the form in which the acpi_temperature criterion is used in the configuration above, the temperature is taken as the average for all these zones.
In general, cpufreqd allows you to specify a specific temperature zone for observation, and you can try to specify the processor thermal zone, but for now this feature looks more like a bug :) there are errors in the code. And you can watch the temperature change in the thermal zones with the help of the command. $ watch cat /proc/acpi/thermal_zone/*/temperature
I hope this was useful.PS In general, I am terribly lacking in cpufreqd the ability to work with states. That is, the ability to use something like this in the rules: if I am able to 'go up', or 'I am able to be cruel throttling'. Because, it is clear that if we go up, and at the next frequency switching step, our load has dropped from 50 percent to 25, this does not mean that it’s time to go down. And in the cpufreqd rule system, it’s not clear how to express it. Therefore, if someone screwed a statefull plugin to cpufreqd, it would be great. I myself do not have the time and energy for this, unfortunately.