La mise à l'échelle de la fréquence du processeur ne fonctionne pas comme prévu sur Vanilla Ubuntu 16.04
L'échelle de fréquence cpu de mon ordinateur portable (processeur Intel i7-4810MQ Core (TM) i7-4810MQ à 2,80 GHz) ne fonctionne pas comme prévu. Après l'installation initiale d'ubuntu 16.04, je n'ai apporté aucune modification concernant la gestion de l'alimentation ou la mise à l'échelle de la fréquence du processeur. Normalement, je suis habitué au deuxième gouverneur. Cependant, il semble que ce gouverneur ait été remplacé par un pstate thingy et le gouverneur powersave dans les nouveaux noyaux.
Même sans charge, les fréquences de l'unité centrale planent autour de la plage 2.x, ce qui provoque le bruit des ventilateurs et le réchauffement de l'appareil:
$ cat /proc/cpuinfo |grep -i mh
cpu MHz : 3435.468
cpu MHz : 2245.468
cpu MHz : 2800.218
cpu MHz : 2338.765
cpu MHz : 2800.546
cpu MHz : 2801.203
cpu MHz : 2800.875
cpu MHz : 2000.140
$ uptime
14:57:49 up 5:15, 1 user, load average: 0,01, 0,08, 0,16
$ cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to [email protected], please.
analyzing CPU 0:
driver: intel_pstate
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 0.97 ms.
hardware limits: 800 MHz - 3.80 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 800 MHz and 3.80 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 2.80 GHz.
analyzing CPU 1:
driver: intel_pstate
CPUs which run at the same hardware frequency: 1
CPUs which need to have their frequency coordinated by software: 1
maximum transition latency: 0.97 ms.
hardware limits: 800 MHz - 3.80 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 800 MHz and 3.80 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 2.80 GHz.
analyzing CPU 2:
driver: intel_pstate
CPUs which run at the same hardware frequency: 2
CPUs which need to have their frequency coordinated by software: 2
maximum transition latency: 0.97 ms.
hardware limits: 800 MHz - 3.80 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 800 MHz and 3.80 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 2.79 GHz.
analyzing CPU 3:
driver: intel_pstate
CPUs which run at the same hardware frequency: 3
CPUs which need to have their frequency coordinated by software: 3
maximum transition latency: 0.97 ms.
hardware limits: 800 MHz - 3.80 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 800 MHz and 3.80 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 2.80 GHz.
analyzing CPU 4:
driver: intel_pstate
CPUs which run at the same hardware frequency: 4
CPUs which need to have their frequency coordinated by software: 4
maximum transition latency: 0.97 ms.
hardware limits: 800 MHz - 3.80 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 800 MHz and 3.80 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 2.80 GHz.
analyzing CPU 5:
driver: intel_pstate
CPUs which run at the same hardware frequency: 5
CPUs which need to have their frequency coordinated by software: 5
maximum transition latency: 0.97 ms.
hardware limits: 800 MHz - 3.80 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 800 MHz and 3.80 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 2.78 GHz.
analyzing CPU 6:
driver: intel_pstate
CPUs which run at the same hardware frequency: 6
CPUs which need to have their frequency coordinated by software: 6
maximum transition latency: 0.97 ms.
hardware limits: 800 MHz - 3.80 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 800 MHz and 3.80 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 2.90 GHz.
analyzing CPU 7:
driver: intel_pstate
CPUs which run at the same hardware frequency: 7
CPUs which need to have their frequency coordinated by software: 7
maximum transition latency: 0.97 ms.
hardware limits: 800 MHz - 3.80 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 800 MHz and 3.80 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency is 2.79 GHz.
Curieusement, j’ai aussi observé le comportement inverse: la machine était soumise à une charge élevée mais les fréquences ont été diminuées jusqu’à env. 20-30sec tous les cœurs ont atteint ~ 800 MHz. J'ai vérifié avec cpufreq-info et la configuration semblait correcte (gouverneur Powersave, fréquence minimale/maximale aux niveaux appropriés). Malheureusement, je suis incapable de reproduire l'erreur ...
Avez-vous une idée des causes de ces problèmes d’échelle ou de ce qui pourrait être fait pour les résoudre?
Sommaire
Oui, dans certaines conditions, la version actuelle du pilote intel_pstate peut augmenter la fréquence de l'UC sous des charges relativement faibles. Cependant, et cela n’entraînera généralement PAS "des ventilateurs et un réchauffement de l’appareil", car les processeurs concernés effectuent leur travail plus rapidement et passent donc plus de temps en état de veille profonde, ce qui neutralise la puissance active plus élevée. Je n'ai jamais pu attribuer à ce problème qu'une puissance supplémentaire d'environ 1/2 watt.
En ce qui concerne la deuxième partie de votre question, à propos de la diminution des fréquences du processeur sous forte charge. Je ne peux que supposer qu’une sorte de limitation thermique est impliquée.
Détails
Il est très important de définir "sans charge" ou "inactif". Pourquoi? Parce que sur un système basé sur une interface graphique, "inactif" a en fait beaucoup de travail à faire. Sur un système basé sur un serveur autre qu'une interface graphique, "inactif" signifie généralement qu'il y a très peu de travail à faire.
Sur les systèmes basés sur une interface graphique, la manifestation de ce problème dépend: du taux de Hz du noyau (100, 250, 300 ou 1000 Hz); Le taux de trame du pilote vidéo; Combien de choses de fond se passe-t-il? La façon dont le planificateur tourne entre les processeurs; Quelques autres choses que j'oublie pour le moment.
Bien qu'un correctif temporaire ait été ajouté, il ne couvre que les charges réelles de 1% ou moins, mais cette condition peut également se produire pour des charges supérieures à 1%. De plus, je ne sais pas si ce correctif est dans, ou a été rétroporté, dans le noyau 16.04 actuel.
Un meilleur correctif est en cours, mais il le sera avant sa publication.
Entre-temps, et si vous le souhaitez, vous pouvez revenir au pilote acpi-cpufreq. Voir ici ou ici pour savoir comment.
Références
https://bugzilla.kernel.org/attachment.cgi?id=187781
https://bugzilla.kernel.org/show_bug.cgi?id=93521
https://bugzilla.kernel.org/show_bug.cgi?id=115771
http://marc.info/?l=linux-pm&m=147000845531378&w=2
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ffb810563c0c049872a504978e06c8892104fb6c