Mon CPU n'allait pas bien. J'avais changé l'AMD Athlon x2 pour un Phenom x4 965, parce que j'en ai récupéré un et parce que les specs de ma carte mère montraient que c'était possible. Par la suite, la carte graphique PCI-E avait laché. Et je cherchais une solution logicielle pour que tout cela fonctionne mieux, le manque d'une bonne carte graphique se faisant sentir je cherchais une compensation.
Premier essai avec cpufreq-set, mais là, quand j'ai voulu positionner le gouverneur sur
performance, suprise : ça ne le faisait que sur le CPU0, les trois autres restaient sur "ondemand". Une recherche sur le web plus tard j'appris 2 choses : en 2013 Phoronix dans un article indiquait que dorénavant, performance était préférable à "ondemand". Comme ça rejoignait ce que je pensais et que je ne voulais pas prendre le temps de tout lire, ça me convenait. Deuxièmement, c'est la commande "cpupower" qu'il fallait employer pour que les 4 cœurs soient positionnés sur "performance" tous en même temps. (Sur performance ou sur un autre gouverneur si vous le voulez, mais dans mon cas c'est celui que je veux).
Cela donne :
sudo cpupower frequency-set -g performance
Super ! Problème réglé ? Non pas tout à fait. Au reboot suivant, cpufreq-info me montrait que les procs étaient de nouveau sur "ondemand". Et lors du boot, en regardant les messages, j'ai vu que LSB envoyait la commande à … je ne sais plus quoi, ça passe trop vite, et bref, ondemand !
Nouvelle recherche sur le web, vite trouvé l'info, il fallait copier le fichier cpufrequtils.sample disponible sous /usr/share/doc/cpufrequtils/examples vers /etc/default/cpufrequtils, et le configurer.
Explications dans le README.Debian trouvé sous /usr/share/doc/cpufrequtils/, et dans les commentaire du fichier cpufrequtils. En français : quelles limites attribuer. Les deux limites minimum et maximum "MIN_SPEED" et "MAX_SPEED" sont des valeurs listées que l'on trouvera avec la commande
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
Et contrairement à celles fournies par cpufreq-info, elles sont fournies dans le format souhaité pour ce fichier (je ne sais pas nommer l'équivalence, exemple 800Mhz = 800 000 je ne sais quoi, et ce 800 000 est le chiffre qu'il faut utiliser dans le fichier).
Donc, chez moi:
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
3400000 2700000 2200000 800000
Le contenu de mon fichier cpufrequtils placé sous /etc/default:
# Which governor to use. Must be one of the governors listed in:
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
#
# and which limits to set. Both MIN_SPEED and MAX_SPEED must be values
# listed in:
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
# a value of 0 for any of the two variables will disabling the use of
# that limit variable.
#
# WARNING: the correct kernel module must already be loaded or compiled in.
#
# Set ENABLE to "true" to let the script run at boot time.
#
# eg: ENABLE="true"
# GOVERNOR="ondemand"
# MAX_SPEED=1000000
# MIN_SPEED=500000
ENABLE="true"
GOVERNOR="performance"
MAX_SPEED=3400000
MIN_SPEED=800000
Il manquait une dernière chose pour que ça tienne passé le reboot, et une dernière recherche plus tard:
$ sudo systemctl disable ondemand
et comme ça se passe sur une version Ubuntu (Bento) 16.04, la console me répondit:
ondemand.service is not a native service, redirecting to systemd-sysv-install
Executing /lib/systemd/systemd-sysv-install disable ondemand
insserv: warning: current start runlevel(s) (empty) of script `ondemand' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (2 3 4 5) of script `ondemand' overrides LSB defaults (empty).
insserv: warning: current start runlevel(s) (empty) of script `ondemand' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (2 3 4 5) of script `ondemand' overrides LSB defaults (empty).
Depuis, j'ai par défaut le gouverneur que je souhaitais pour mon processeur démarrage après démarrage.
* melodie contente !