# [Frequency scaling] un effet de bord amusant (résolu)

## anigel

Hello !

Chacun d'entre nous pourrait un jour être confronté au problème, je vous fais donc profiter de mes "expériences"... J'ai changé de machine la semaine dernière. Changement de carte mère, de disque dur, etc... J'en ai profité pour mettre ma gentoo à jour, et passer sur un des derniers noyaux (2.6.14). J'ai activé le frequency scaling, qui marche (trop) parfaitement. Au repos, mon CPU tourne à... 400 Mhz, au lieu de 2,8 Ghz. Inutile de préciser que niveau température, ça n'a pas grand-chose à voir non plus ! Bref, le pied. J'ai aussi activé l'aliasage des fontes dans xorg, la totale. Et là, je lance mon X. Enjoy... pendant 3 secondes. C'est horriblement lent ! Ca raaaaaaaaaaaaaame ! Je quitte X, histoire de relancer une autre session, voir si par hasard ça irait mieux (j'étais sous gnome, je passe donc sous fluxbox). PAF, crash du serveur X. Renseignements pris, c'est une "fonctionnalité des drivers ATI". C'est tty qui m'a fourni la solution (merci à lui) :

```
Option "AGPMask"    "0x00000006"

Option "AGPv3Mask"  "0x00000006"
```

Effectivement, ça ne crash plus. Zut  alors, je viens de perdre une fonction intéressante de ces drivers  :Wink: .

Par contre, mon problème de lenteur persiste... Je fais quelques tests basiques, et je constate déjà que "top" dans un gnome-terminal me prend minimum 20% de mon 3Ghz, alors que le même top, dans un xterm me prend 1%, le vent dans le dos. Même dans firefox, ça rame grave : les gestures ne fonctionnent pas tellement le système est peu réactif ! Je penche alors pour un problème de gestion des fontes. Que nenni ! C'est emerge qui m'a fait prendre conscience de ce qui déconnait : j'ai lancé une compilation, et là, mon système est redevenu réactif, plus aucun problème  :Neutral:  !!!

Conclusion basique : le système devient réactif lorsqu'il est chargé  :Arrow:  je viens de découvrir l'ordinateur quantique ! Et ben non, même pas. C'est juste que le frequency scaling du noyau, avec le governor "ondemand" ne réagit pas assez vite ! D'où mes problèmes de gestures dans firefox : c'est typiquement un truc qui prend moins d'une seconde, et le kernel n'a pas le temps de remonter la fréquence CPU à une valeur suffisante. Quelle solution alors ?

En plus de echo "ondemand" >> /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

Il faut ajouter echo 699982 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq

Notez que les valeurs possible pour votre CPU sont disponibles dans /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies

Voilà voilà, des fois que ça pourrait aider  :Wink: .

----------

## guilc

Bizarre, je n'ai jamais eu ce problème.

Ptet que ça tient a ma conf que je te colle ci-après (sous la forme d'un petit script d'init que je me suis concoté) :

```
$ cat /etc/init.d/cpu-ondemand

#!/sbin/runscript

# Copyright 1999-20045 Gentoo Foundation

# Distributed under the terms of the GNU General Public License v2

opts="${opts} min max"

depend() {

    need localmount

}

start() {

    ebegin "Setting ondemand governor"

    echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

    echo 1        > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice

    echo 25       > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold

    echo 2        > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_down_factor

    cat /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate_min > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate

    eend $?

}

max() {

    ebegin "Setting performance governor"

    echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

    eend $?

}

min() {

    ebegin "Setting powersave governor"

    echo powersave > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

    eend $?

}

stop() {

    ebegin "Setting default (performance) governor"

    max

    eend $?

}

```

Si ça peut aider...

----------

## anigel

Merci pour cette astuce !

Ca améliore un peu les perfs, mais ça reste en-deça de ce que ça devrait être. Le système réagit plus vite qu'avant, mais toujours avec un peu de latence. As-tu des détails sur les valeurs que tu modifies ? J'ai fouiné un peu partout, mais je n'ai rien trouvé qui explique en quoi ces valeurs agissent sur le fonctionnement du scaling.

J'en ai un peu parlé autour de moi, et un ami, qui possède un p-m me dit que lui n'a jamais rencontré ce problème... D'un autre côté, mon P4, qui est prévu pour fonctionner, de base, à 2,8 Ghz, descend quand même à 350Mhz... Soit moins que la fréquence du bus qui l'alimente ! Alors que la fréquence minimale du p-m se situe dans les 600 Mhz, soit déjà le double (au passage, il s'agit de la valeur sur laquelle je m'étais basé, empiriquement, pour obtenir un comportement suffisamment réactif). Mais je ne demande pas mieux que de revoir ma copie  :Wink: .

Merci d'avance.

EDIT : J'en profite au passage pour rajouter une petite ligne de commande, permettant d'obtenir la fréquence du CPU0 à un moment donné, en Mhz, c'est un peu plus lisible :

```
alias cpufreq='echo $((`cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq` / 1000))'
```

----------

## spider312

 *anigel wrote:*   

> EDIT : J'en profite au passage pour rajouter une petite ligne de commande, permettant d'obtenir la fréquence du CPU0 à un moment donné, en Mhz, c'est un peu plus lisible :
> 
> ```
> alias cpufreq='echo $((`cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq` / 1000))'
> ```
> ...

 

```
grep MHz /proc/cpuinfo
```

 le fait sans passer par cpufreq pour info  :Wink: 

Sinon, pour le problème dont tu parles, diminuer la fréquenc eà 300 MHz, c'est un peu violent quand même, qu'est-ce qui ne te convient pas dans le fait d'utiliser une fréquence mini plus élevée ? (mon P-M descend jusqu'à 800 MHz, fréquence à laquelle il est tres react), surtout qu'il s'agit d'un PC fixe à ce que j'ai compris, donc l'interet du frequency scaling est quand même assez limité ...

La chaleur est un problème uniquement à pleine charge, hors avec ce système, à pleine charge, la t° est la même que sans ce système, je crois même que c'est plutôt déconseillé, mieux vaut une t° qui ne varie pas trop que trop refroidir le CPU et le laisser monter haut

----------

## anigel

 *spider312 wrote:*   

> 
> 
> ```
> grep MHz /proc/cpuinfo
> ```
> ...

 

/proc est appelé à disparaître à terme, et à être remplacé par /sys. J'ai juste pris l'habitude d'aller chercher les infos là, surtout que c'est quand même vachement mieux rangé que dans /proc  :Wink: . Notes que dans les 2 cas tu as accès aux même valeurs du noyau ^^.

 *spider312 wrote:*   

> Sinon, pour le problème dont tu parles, diminuer la fréquence à 300 MHz, c'est un peu violent quand même, qu'est-ce qui ne te convient pas dans le fait d'utiliser une fréquence mini plus élevée ? (mon P-M descend jusqu'à 800 MHz, fréquence à laquelle il est tres react), surtout qu'il s'agit d'un PC fixe à ce que j'ai compris, donc l'interet du frequency scaling est quand même assez limité ...

 

Ce n'est pas violent, c'est la valeur minimum supportée par ce CPU. Et puis, tout dépend... J'ai entrepris depuis plusieurs années un gros travail sur tout ce qui est nuisances (sonores, thermiques), et sur la gestion de la consommation d'énergie. Sur un PC, ça ne change pas grand-chose. Sur les presque 200 que je gère en salles de TP, ça devient déjà plus probant. A l'échelle d'une salle de 16 postes, en fin de journée, la différence est de presque 4° si les PC ont tourné toute la journée. Je te laisse imaginer en été ce que ça peut donner !

Alors à l'échelle d'un pays entier, ou même de la planète, il reste 2 écoles : "j'm'en tape, de toute façon c'est pas mon PC qui va changer quoi que ce soit au réchauffement climatique" ou alors "même si ça ne change presque rien, au moins j'aurais essayé". Dans la mesure où ça coûte moins cher, où les ventilos tournent moins vite, où la consommation électrique de mon réseau a été divisée par 2,5 l'an dernier, je me dis que finalement, l'intérêt est énorme au contraire !

 *spider312 wrote:*   

> La chaleur est un problème uniquement à pleine charge, hors avec ce système, à pleine charge, la t° est la même que sans ce système, je crois même que c'est plutôt déconseillé, mieux vaut une t° qui ne varie pas trop que trop refroidir le CPU et le laisser monter haut

 

C'est surtout vrai sur les laptops. Sur les CPU "de bureau", la température normale de fonctionnement actuelle se situe autour de 60°. Celui du CPU que j'utilise pour ces tests est d'environ 47°. Depuis que j'ai mis en place le scaling, je suis tombé à 38°... Tout le problème consiste à réussir à combiner ces fonctionnalités d'économie d'énergie avec le niveau de réactivité auquel les utilisateurs s'attendent.

----------

## anigel

Allez, pour le plaisir du geek, une dernière version du script, sous forme de fonction bash, en couleurs avec support SMP !

```
__GREEN="\033[32;01m"

__RED="\033[31;01m"

__LIGHT_BLUE="\033[36;01m"

cpufreq () {

   for CPU in `ls /sys/devices/system/cpu/` ; do

       echo -en "$__GREEN *$__LIGHT_BLUE Current $CPU frequency : $__RED"

       echo $((`cat /sys/devices/system/cpu/$CPU/cpufreq/cpuinfo_cur_freq` / 1000)) "Mhz";

   done

}
```

----------

## bibi.skuk

tiens, ca marche pas chez moi

```

[keymaker@alastor]~%ls /sys/devices/system/cpu/cpu0                       12:54

[keymaker@alastor]~%                                                      12:55

```

----------

## spider312

Tu n'as visiblement pas compris ce que je voulais dire

Un processeur supportera moins de passer sans arret de 30° à 40° et de 40° à 50° que de rester à 40-45° puis de monter à 50° de temps en temps, vouloir toujours baisser la t° de son pross n'est pas bon pour lui ... les contrastes de t° sont plus mauvais que les temperatures élevées

Après, pour la t° de la piece, ok, je ne pensais pas que tu le faisais pour plusieurs PCs, et honetement, plusieurs PCs dans la même salle avec gentoo, j'éviterais, le jour ou une MAJ de sécu de Firefox et Thunderbird sort, t'as interet que ce soit en hiver et ouvrir les fenetres ...

----------

## anigel

 *spider312 wrote:*   

> Un processeur supportera moins de passer sans arret de 30° à 40° et de 40° à 50° que de rester à 40-45° puis de monter à 50° de temps en temps, vouloir toujours baisser la t° de son pross n'est pas bon pour lui ... les contrastes de t° sont plus mauvais que les temperatures élevées

 

Ca, je ne saurais le dire, n'étant pas électronicien moi-même. Mes collègues plus calés que moi sur ce sujet ont adopté la même politique, alors j'en déduis que ça ne doit pas être si dangereux que ça ?  De plus la température ne varie pas plus avec cette config qu'avec la config originale : avant, j'oscillais entre 47 et 55°, aujourd'hui j'oscille entre 38 et 45. Et si la compil est vraiment longue, alors la température continue de monter doucement jusqu'à atteindre 55. Ensuite elle redescend : bref, à priori, les changements n'ont rien de vraiment violent.

 *spider312 wrote:*   

> Après, pour la t° de la piece, ok, je ne pensais pas que tu le faisais pour plusieurs PCs, et honetement, plusieurs PCs dans la même salle avec gentoo, j'éviterais, le jour ou une MAJ de sécu de Firefox et Thunderbird sort, t'as interet que ce soit en hiver et ouvrir les fenetres ...

 

J'ose à peine imaginer ce que ce serait, effectivement. Mais je n'ai jamais expérimenté ça : j'ai des machines qui vont du Duron 600 au P4 3,2 Ghz, alors pour simplifier, j'ai créé mon propre repository de binaires, pré-compilés par mes soins sur une machine "témoin".

Mais on s'écarte du sujet : ce que je cherchais, c'est surtout la signification et les implications de changements dans les valeurs données ci-dessus, histoire de régler ça "aux petits oignons".

Amicalement,

----------

## marvin rouge

C'est bizarre ton problème, et cette fréquence si basse. Avec ondemand je n'ai jamais rencontré ça (je suis pas sur le même proc, j'ai un amd64 3500+)

Sinon je fait différement. Dans /etc/conf.d/local.start j'ai mis:

```
echo "ondemand" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice

echo 25 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold
```

(la dernière ligne, je l'ai rajoutée après le post de guilc ci dessus, pour tester, sinon la valeur par défaut doit être autour de 70).

Ca me donne un système suffisament réactif, et qui chauffe pas (25°C en iddle, 48 chargé à 3, cohérent avec les mesures du bios).

Mon ptit grain de sel à 2 cents.

+

----------

## spider312

 *anigel wrote:*   

> Ce n'est pas violent, c'est la valeur minimum supportée par ce CPU. Et puis, tout dépend... 

 Euh, du coup,n tu n'as pas répondu à ma remarque *spider312 wrote:*   

> qu'est-ce qui ne te convient pas dans le fait d'utiliser une fréquence mini plus élevée ?

 Il ne te viendrais pas à l'idée de configurer ton WM et toutes tes applis  de la même façon si tu utilisais un CPU à 350, alors c'est normal que ça pose problème, personellement, j'utiliserais une fréquence minimale potable quand même (800 c'est pas mal, au pire 500-600 te permet des bonnes perfs sur les CPU actuels), pourquoi la soluce de monter la fréquence minimale ne te convient-elle pas ?

----------

## anigel

Euh, si, je croyais avoir répondu à la remarque au contraire ?

Mon impératif n'est pas d'avoir 3 Ghz sous le capot en permanence. C'est seulement d'avoir accès à la puissance rapidement, lorsque j'en ai besoin (un peu comme une voiture ne roule pas en permanence à 90, mais doit pouvoir les atteindre rapidement en cas de besoin, pour dégager la route par exemple). Et, le reste du temps, les questions d'économie d'énergie, à l'échelle de mon parc, sont suffisamment significatives pour que je passe quelques heures à résoudre ce problème.

 :Arrow:  Donc, ce qui me gêne dans le fait de faire tourner mon CPU à 1 Ghz lorsque je pourrais ne le faire tourner qu'à 350 Mhz, c'est principalement la consommation électrique supplémentaire induite (une salle de TP qui ne sert pas entre 12H et 15H, ce n'est pas rare. Dans cet intervalle, mes écrans sont mis en veille, les CPU passent en mode veille aussi, etc...).

 *spider312 wrote:*   

> Il ne te viendrais pas à l'idée de configurer ton WM et toutes tes applis de la même façon si tu utilisais un CPU à 350, alors c'est normal que ça pose problème, personellement, j'utiliserais une fréquence minimale potable quand même (800 c'est pas mal, au pire 500-600 te permet des bonnes perfs sur les CPU actuels), pourquoi la soluce de monter la fréquence minimale ne te convient-elle pas ?

 

Je te le confirme : effectivement, je n'aurais pas configuré une machine à 350 Mhz comme mon P4 à 2,8 Ghz (rassuré sur mon état mental ?  :Laughing: ). Mais bon, je n'ai pas envie de tout répéter une é-nième fois, alors je t'invite à relire tout ce que j'ai écrit plus haut  :Wink: .

Pour essayer de résumer les choses, je dirais que, tout comme aujourd'hui on ne s'étonne plus de la réactivité d'un noyau 2.6 par rapport à un 2.4 (préemptivité oblige), je recherche le même type de gestion, mais pour la fréquence du CPU. Et guilc m'a déjà donné un élément de réponse, que je souhaiterais compléter en connaissance de cause, avec la spécification précise des valeurs modifiées.

Et pour conclure, plutôt que la "démonstration" que ce que je fais est idiot, je préfèrerais largement des éléments de réponses à mes questions, comme guilc l'a fait (même si ce n'est pas suffisant, c'est déjà largement meilleur, toujours avec un minima à 350 Mhz  :Shocked:  .

----------

## guilc

anigel >

Perso, moi aussi c'est un 2.8GHz qui descend a 350MHz, et je n'ai pas de pbs de latences avec mon script. Quand je suis a 350MHz, si y a besoin de puissance, la latence est suffisament faible pour que la remontée en fréquence se fasse avant que ça laggue.

Et pour la doc, perso, j'ai fait avec les sources du ondemand (/usr/src/linux/drivers/cpufreq/cpufreq_ondemand.c), y a des infos pas mal :

```

 41  * The polling frequency of this governor depends on the capability of

 42  * the processor. Default polling frequency is 1000 times the transition

 43  * latency of the processor. The governor will work on any processor with

 44  * transition latency <= 10mS, using appropriate sampling

 45  * rate.

 46  * For CPUs with transition latency > 10mS (mostly drivers with CPUFREQ_ETERNAL)

 47  * this governor will not work.

 48  * All times here are in uS.

 49  */

```

Def des valeurs min/max :

```

 51 #define MIN_SAMPLING_RATE           (def_sampling_rate / 2)

 52 #define MAX_SAMPLING_RATE           (500 * def_sampling_rate)

 53 #define DEF_SAMPLING_RATE_LATENCY_MULTIPLIER    (1000)

 54 #define DEF_SAMPLING_DOWN_FACTOR        (1)

 55 #define MAX_SAMPLING_DOWN_FACTOR        (10)

 56 #define TRANSITION_LATENCY_LIMIT        (10 * 1000)

```

Valeurs tweakables :

```

 73 struct dbs_tuners {

 74     unsigned int        sampling_rate;

 75     unsigned int        sampling_down_factor;

 76     unsigned int        up_threshold;

 77     unsigned int        ignore_nice;

 78 };

```

Et analyse du reste du code poru savoir précisément quel paramètre a quel effet.

C'est grace a ça que j'ai découvert que dans les version plus récentes du 2.6, mettre ignore_nice a 1 comptera le temps cpu nicé dans le temps total (donc en fait, ne l'ignore pas, le nom est un peu foireux), alors que sur les versions plus anciennes, c'est l'inverse...

----------

## LostControl

 *anigel wrote:*   

> un peu comme une voiture ne roule pas en permanence à 190, mais doit pouvoir les atteindre rapidement en cas de besoin, pour dégager la route par exemple

 

Petite correction pour un exemple plus réaliste  :Laughing: 

----------

## anigel

 *marvin rouge wrote:*   

> C'est bizarre ton problème, et cette fréquence si basse. Avec ondemand je n'ai jamais rencontré ça (je suis pas sur le même proc, j'ai un amd64 3500+)

 

En fait, la lecture du fichier /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies me renvoie : 349991 699982 1049973 1399965 1749956 2099947 2449938 2799930

Ces nombres correspondent, en Hz, aux différentes fréquences supportées par mon CPU. Que contient ce fichier chez toi ?

 *marvin rouge wrote:*   

> Sinon je fait différement.
> 
> [...]
> 
> la dernière ligne, je l'ai rajoutée après le post de guilc ci dessus, pour tester, sinon la valeur par défaut doit être autour de 70).
> ...

 

J'ai fait quelques ajustements aussi, après le post de guilc. Mais je n'arrive pas à trouver la signification des différentes valeurs contenues dans ces fichiers. Après quelques tâtonnements, j'ai un comportement largement meilleur, mais ça reste perfectible je pense. Par contre, chapeau bas : 25°C sur un Athlon64, même au repos, c'est surprenant, non ?

----------

## anigel

Merci guilc  :Smile: 

J'avais eu le réflexe de lire la doc, mais pas celui de lire les sources   :Shocked:  . Je vais m'y pencher un peu mieux.

@ LostControl : Et c'est une suisse qui écrit ça...  :Laughing:  !

----------

## marvin rouge

 *anigel wrote:*   

>  *marvin rouge wrote:*   C'est bizarre ton problème, et cette fréquence si basse. Avec ondemand je n'ai jamais rencontré ça (je suis pas sur le même proc, j'ai un amd64 3500+) 
> 
> En fait, la lecture du fichier /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies me renvoie : 349991 699982 1049973 1399965 1749956 2099947 2449938 2799930
> 
> Ces nombres correspondent, en Hz, aux différentes fréquences supportées par mon CPU. Que contient ce fichier chez toi ?

 

Voilà:

```
$  cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies

2200000 2000000 1800000 1000000
```

La plupart du temps, je suis à 1GHz. Si ça monte en utilisation, la montée en fréquence se fait rapidement à 2.2 GHz (avec un petite latence, mais très supportable), et la redescente se fait par paliers.

 *anigel wrote:*   

> 
> 
> J'ai fait quelques ajustements aussi, après le post de guilc. Mais je n'arrive pas à trouver la signification des différentes valeurs contenues dans ces fichiers. Après quelques tâtonnements, j'ai un comportement largement meilleur, mais ça reste perfectible je pense. Par contre, chapeau bas : 25°C sur un Athlon64, même au repos, c'est surprenant, non ?

 

Il fait très froid chez moi (pour des raisons indépendantes de la fréquence de mon proco   :Wink:  )

J'avais un peu tatonné (assez peu) il y a quelques mois, et puis ça fonctionnait bien comme ça, alors je n'ai pas poussé plus loin.

+

EDIT j'oubliais, pour la température de mon proc : j'ai un gros radiateur (XP-120 de thermalright, il me semble), avec un ventilo 120 mm. Ca chauffe moins qu'avec le ventilo d'origine.

----------

## boozo

'alute

 :Shocked:  alors là... je dois dire que chapeau Mr. guilc   :Cool:   (Anigel et les autres aussi hein...)

çà faisait longtemps que je me tatais pour me mettre un frequency scaling aux petits oignons alors j'ai bien lu tout vos travaux et j'me suis lancé - en plus j'avais un 2.6.14 qui me causait pb sur le X c'était donc l'occasion   :Wink:  -

C'est NICKEL !!   :Very Happy:   un vrai régal... réactif, pas de lag (certes faut dire que le big preemptible kernel du 2.6.14 aide bien mais bon   :Laughing:  )  je monte depuis d'un 2.6.13.r5 en performance et je tourne maintenant deux fois plus vite et avec le ondemand en plus   :Shocked: 

</me fait des petits bonds un peu partout dans le salon> C'est le top... et moi j'en suis baba   :Laughing: 

Un grand merci a vous tous   :Very Happy: 

----------

## yabo

Euh j'ai l'impression que vous vous compliquez la vie en fait.

En fait la solution propre sans passer par l'édition de sources etc, ca serait de définir des règles et des profils dans le cpufreqd.conf.

Par exemple :

```

[General]

pidfile=/var/run/cpufreqd.pid

poll_interval=2

pm_type=acpi #(acpi, apm or pmu)

# On définit 3 profiles. Un qui utilise la puissance maximale du CPU, un autre qui l'utilise à moitié environ, et l'autre au minium.

[Profile]

name=hi_boost

ac=on

minfreq=1800000

maxfreq=2200000

policy=performance

[Profile]

name=medium_boost

ac=on

minfreq=1800000

maxfreq=1800000

policy=performance

[Profile]

name=low_boost

minfreq=800000

maxfreq=800000

policy=powersave

# Quand on est sur batterie, on économise la batterie et peu importe les perfs

[Rule]

name=conservative

ac=off

battery_interval=0-100

cpu_interval=0-100

profile=lo_power

# On considère qu'entre 0 et 39 % d'utilisation CPU, 800 Mhz suffisent

[Rule]

name=no_cpu_boost

ac=on

cpu_interval=0-39

profile=lo_power

# entre 40 et 75 % d'utilisation CPU on consent à passer à 1.8 Ghz

[Rule]

name=medium_cpu_boost

ac=on

cpu_interval=40-75

profile=medium_boost

# de 76 à 100% on utilise le processeur au maximum de ce qu'il peut fournir

[Rule]

name=hi_cpu_boost

ac=on

cpu_interval=76-100

profile=hi_boost

# Règle qui permet d'utiliser toute la puissance du CPU si on compile ou lit un DVD peu importe si on est sur la batterie ou pas

[Rule]

name=heavy_usage

programs=xine,mplayer,avidemux,make,gcc,g++

profile=hi_boost

```

Avec ce genre de configs on peut vraiment peaufiner la conf de cpufreqd sans toucher aux sources et en ayant une réactivité vraiment maximale, dépendant des programmes qu'on utilise etc. Ici c'est dans le cadre d'un laptop pour un amd64 3400+. Et sinon y a pleins d'autres options mais que je n'utilise pas, pour ca, se référer à la doc  :Wink: 

----------

## guilc

Non, ce n'est pas se compliquer la vie : c'est utiliser le frequence scaling qui est bien paramétrable au niveau du kernel maintenant sans l'adjonction d'un programme en userland  :Smile: 

----------

