web-dev-qa-db-fra.com

La définition des limites du processeur graphique dans Ubuntu 17.04 ne fonctionne plus

J'utilisais Ubuntu MATE 16.04 auparavant, mais je suis passé récemment à 17.04 car il est venu avec la mise à jour de Thermald et je suppose que cela corrigera les bugs comme celui-ci pour moi. J'ai eu des problèmes avec thermald dans Ubuntu 16.04 similaire à celui décrit ici, mais étant donné qu'il a été corrigé dans thermald (1.5.4-3) et que Ubuntu 17.04 est venu avec une version mise à jour par défaut, j'ai supposé que cela fonctionnerait mieux pour moi. dans l’ensemble, avec éventuellement un système fixe partout. J'ai donc installé 17.04, essayé, tout fonctionnait bien, j'ai donc migré complètement.
Après un certain temps, j’ai rencontré un problème très étrange avec un système ignorant complètement les limites définies du processeur. En 16.04, il ne m’est arrivé que lorsque Intel GPU essayait de travailler sur une fréquence liée à un état de fonctionnement du processeur supérieur aux limites. Par exemple, si je lance:

Sudo cat /sys/kernel/debug/dri/1/i915_ring_freq_table

Ceci est ma sortie:

GPU freq (MHz)  Effective CPU freq (MHz)    Effective Ring freq (MHz)
650             800                         0
700             800                         0
750             1400                        0
800             1500                        0
850             1600                        0
900             1600                        0
950             1700                        0
1000            1800                        0
1050            1900                        0
1100            2000                        0

Donc, si je veux que mon processeur fonctionne à 1 500 MHz maximum et ne monte pas plus haut, cela signifie que le GPU doit être limité à 800 MHz et ne jamais aller plus haut, car ils sont liés car il s'agit d'un GPU intégré au processeur.
Sous Ubuntu 16.04, j’ai défini manuellement les limites du GPU en écrivant dans /sys/kernel/debug/dri/1/i915_max_freq valeur que je veux être la limite maximale que mon GPU peut utiliser. Lorsque je limite le processeur à 1500 MHz, je lance également:

echo 800 | Sudo tee /sys/kernel/debug/dri/1/i915_max_freq

Et mon GPU restera dans la plage, sans déranger les fréquences de travail du processeur.
Cependant, dans Ubuntu 17.04, une fois les limites définies, le GPU atteint encore 1100 MHz, ce qui rend toute limite de CPU inutile et surchauffe le processeur.

~$ Sudo cat /sys/kernel/debug/dri/1/i915_max_freq
800

Comme vous pouvez le constater, la limite est définie et en place. Nous vérifions maintenant frequency_info:

~$ Sudo cat /sys/kernel/debug/dri/1/i915_frequency_info
PM IER=0x00000070 IMR=0xffffff8f ISR=0x00000000 IIR=0x00000000, MASK=0x0000002a
pm_intr_keep: 0x00000004
GT_PERF_STATUS: 0x000016cb
Render p-state ratio: 22
Render p-state VID: 203
Render p-state limit: 255
RPSTAT1: 0x00041610
RPMODECTL: 0x00000d92
RPINCLIMIT: 0x000019fa
RPDECLIMIT: 0x00003a98
RPNSWREQ: 1100MHz
CAGF: 1100MHz
RP CUR UP EI: 7165 (9171us)
RP CUR UP: 7006 (8967us)
RP PREV UP: 6725 (8608us)
Up threshold: 85%
RP CUR DOWN EI: 1314 (1681us)
RP CUR DOWN: 1315 (1683us)
RP PREV DOWN: 23741 (30388us)
Down threshold: 60%
Lowest (RPN) frequency: 650MHz
Nominal (RP1) frequency: 650MHz
Max non-overclocked (RP0) frequency: 1100MHz
Max overclocked frequency: 1100MHz
Current freq: 1100 MHz
Actual freq: 1100 MHz
Idle freq: 650 MHz
Min freq: 650 MHz
Boost freq: 1100 MHz
Max freq: 1100 MHz
efficient (RPe) frequency: 650 MHz
Current CD clock frequency: 400000 kHz
Max CD clock frequency: 400000 kHz
Max pixel clock frequency: 360000 kHz

Nous pouvons voir que la fréquence actuelle et réelle est au maximum de 1100 MHz.
Cela abaisse également la fréquence du processeur, sans tenir compte de sa limite, car le processeur ne peut pas baisser si le processeur graphique atteint un niveau aussi élevé:

~$ Sudo 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 - 2.00 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 1.50 GHz and 1.50 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 2.00 GHz (asserted by call to hardware).
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 - 2.00 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 1.50 GHz and 1.50 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 2.00 GHz (asserted by call to hardware).

Comme vous pouvez le constater, la stratégie est comprise entre 1,50 GHz et 1,50 GHz, mais elle est augmentée au maximum en raison du GPU.

Après avoir fermé l'application graphique:

Sudo cat /sys/kernel/debug/dri/1/i915_frequency_info
PM IER=0x00000070 IMR=0xffffff8f ISR=0x00000000 IIR=0x00000000,
[...]
CAGF: 650MHz
[...]
Lowest (RPN) frequency: 650MHz
Nominal (RP1) frequency: 650MHz
Max non-overclocked (RP0) frequency: 1100MHz
Max overclocked frequency: 1100MHz
Current freq: 650 MHz
Actual freq: 650 MHz
Idle freq: 650 MHz
Min freq: 650 MHz
Boost freq: 1100 MHz
Max freq: 1100 MHz
[...]

Le GPU est revenu au minimum et le processeur fonctionne maintenant avec les limites assignées:

Sudo 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 - 2.00 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 1.50 GHz and 1.50 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 1.12 GHz (asserted by call to hardware).
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 - 2.00 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 1.50 GHz and 1.50 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 1.49 GHz (asserted by call to hardware).

Question: comment faire en sorte que intel GPU respecte la limite définie dans Ubuntu 17.04, de sorte qu'il cesse de jouer avec la limite de mon processeur, et pourquoi il ignore les limites qui fonctionnaient dans 16.04?

Mise à jour: Après avoir fouillé, j'ai trouvé cette chose:

Sudo cat /sys/kernel/debug/dri/0/i915_rps_boost_info
RPS enabled? 1
GPU busy? yes [1 requests]
CPU waiting? 0
Frequency requested 650
  min hard:650, soft:650; max soft:700, hard:1100
  idle:650, efficient:650, boost:1100
Xorg [1221]: 591 boosts
Kernel (anonymous) boosts: 8
RPS Autotuning (current "low power" window):
  Avg. up: 0% [above threshold? 95%]
  Avg. down: 0% [below threshold? 85%]

Quel est ce "RPS", et peut-il être une raison pour laquelle le GPU "booste" au maximum en ignorant les limites définies?

intel-graphics17.04cpui915frequency
1
Ethuil UI

Solution trouvée et cause de mon problème - RPS boost ignorait la limite de fréquence gpu définie.
Au lieu de définir la limite via /sys/kernel/debug/dri/1/i915_max_freq , je suis passée à le configurer /sys/class/drm/card1 , paramètres gt_max_freq_mhz et gt_boost_freq_mhz . Une fois que vous avez défini la limite dans i915_max_freq , la fréquence d’augmentation n’est pas limitée. Ainsi, lorsque les demandes du système sont amplifiées, les limites définies dans (== - sont augmentées) gt_boost_freq_mhz , en ignorant ce que vous définissez.
En exécutant:

echo 800 | Sudo tee /sys/class/drm/card1/gt_max_freq_mhz   
echo 800 | Sudo tee /sys/class/drm/card1/gt_boost_freq_mhz

Je fixe des limites aux valeurs normales et renforcées, et le système ne dépasse plus la limite du processeur graphique, ce qui signifie que la limite du processeur ne sera pas affectée dans mon cas.

Sudo cat /sys/kernel/debug/dri/1/i915_rps_boost_info
RPS enabled? 1
GPU busy? yes [32 requests]
CPU waiting? 0
Frequency requested 800
  min hard:650, soft:650; max soft:800, hard:1100
  idle:650, efficient:650, boost:800
[...]

Étapes à suivre pour appliquer cette solution:

1) Lire le tableau à /sys/kernel/debug/dri/0/i915_ring_freq_table (ou /sys/kernel/debug/dri/1/i915_ring_freq_table dans certains cas:

Sudo cat /sys/kernel/debug/dri/0/i915_ring_freq_table

Trouvez la fréquence du processeur qui a la limite de processeur souhaitée et recherchez la fréquence du GPU qui lui est liée. Ce sera la limite que vous devez définir sur le GPU.

2) Définissez la limite pour la fréquence du processeur graphique en écrivant dans gt_max_freq_mhz et gt_boost_freq_mhz à /sys/class/drm/card0 (peut être cardX selon sur la situation, vérifier manuellement si nécessaire):

echo [GPU_frequency_limit] | Sudo tee /sys/class/drm/cardX/gt_max_freq_mhz /sys/class/drm/cardX/gt_boost_freq_mhz

Par exemple:

echo 800 | Sudo tee /sys/class/drm/card0/gt_max_freq_mhz /sys/class/drm/card0/gt_boost_freq_mhz

3) Vérifiez si les limites ont été atteintes (changez 0 en X si vous avez utilisé cardX:

Sudo cat /sys/kernel/debug/dri/0/i915_rps_boost_info

Vos valeurs maximales et maximum doivent maintenant être modifiées pour correspondre à ce que vous avez défini. .
Sachez que la limitation de la fréquence du processeur graphique peut réduire vos performances OpenGL.

Si vous ne voulez pas utiliser la première solution, vous pouvez essayer une alternative ci-dessous.

Il existe une autre solution alternative qui ne fonctionne pas pour moi en raison de la limitation du BIOS, mais peut fonctionner pour quelqu'un d'autre, ce qui limite la limite de puissance du package, comme l'a suggéré @spandruvada d'Intel sur le fil de discussion de github thermald.

Vous voyez d’abord la valeur actuelle en lisant /sys/class/powercap/intel-rapl/intel-rapl: 0/constraint_0_power_limit_uw :

Sudo cat /sys/class/powercap/intel-rapl/intel-rapl:0/constraint_0_power_limit_uw

Ensuite, vous essayez de changer la valeur limite en lançant:

echo [reduced_power_value] | Sudo tee /sys/class/powercap/intel-rapl/intel-rapl:0/constraint_0_power_limit_uw

Par exemple, dans mon cas, j'avais 35000000 comme valeur initiale et je voulais le changer en 30000000 :

echo 30000000 | Sudo tee /sys/class/powercap/intel-rapl/intel-rapl:0/constraint_0_power_limit_uw

Si vous obtenez "Aucune donnée disponible" après avoir essayé d'écrire dessus, soit elle est simplement désactivée (ce qui peut être vérifié en lisant /sys/class/powercap/intel-rapl/intel-rapl : 0/activé , sera 0 s'il est désactivé) ou verrouillé par le BIOS. Si vous ne pouvez pas l'activer en écrivant 1 pour "activer" l'option, recherchez un message d'erreur pour dmesg (après avoir tenté d'écrire dans constraint_0_power_limit_uw :

dmesg | grep powercap
[29580.025164] powercap intel-rapl:0: package locked by BIOS, monitoring only

Si vous voyez "verrouillé par le BIOS", vous devrez l'activer manuellement dans le BIOS. Si vous ne pouvez pas le faire, vous ne pourrez pas le contrôler et cette méthode ne vous convient pas. D'après ce que je comprends, si vous l'avez activé et qu'il fonctionne, thermald devrait ajuster automatiquement ces valeurs pour vous, sans que vous ayez à les modifier manuellement.

Problème sur github avec cette suggestion
Si vous voulez utiliser cette méthode manuellement, quelques détails supplémentaires à ce sujet ici.

0
Ethuil UI