Le principe d'économie d'énergie est simple. C'est basé sur l'équation :
P = K*F*V2+S
K est un facteur lié à la téchnologie (capa parasite,...)
F est la fréquence
V la tension d'alim
S la fuite de courant
Pour diminuer le courant en idle, tu coupe la clock et tu réduit le terme de conso dynamique.
Tu peux même éteindre une zone complète. Mais "rallumer" prend du temps, le temps que le régulateur se mettent à la bone valeur.
Une fois que l'on coupe tout quand il n'y a rien à faire, il reste à baisser la conso quand le processeur est actif.
Si une tache prends 10 000 coup d'horloge, baisser la fréquence ne change rien. L'énergie pour la tâche est la même (sauf si S >> KFV2 dans ce cas, c'est encore pire).
L'idée est alors de baisser V en même temps que F, dans ce cas on y gagne (S baisse aussi).
La tache sera plus lente mais moins énergivore. Par contre, le problème est la latence pour changer de mode quand le besoin de puissance arrive. D'ou l'idée de gérer les latences dans une API j'imagine.
[^] # Re: API d'annonce de contrainte
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Nouvelle version 2.6.19 du noyau Linux. Évalué à 10.
P = K*F*V2+S
K est un facteur lié à la téchnologie (capa parasite,...)
F est la fréquence
V la tension d'alim
S la fuite de courant
Pour diminuer le courant en idle, tu coupe la clock et tu réduit le terme de conso dynamique.
Tu peux même éteindre une zone complète. Mais "rallumer" prend du temps, le temps que le régulateur se mettent à la bone valeur.
Une fois que l'on coupe tout quand il n'y a rien à faire, il reste à baisser la conso quand le processeur est actif.
Si une tache prends 10 000 coup d'horloge, baisser la fréquence ne change rien. L'énergie pour la tâche est la même (sauf si S >> KFV2 dans ce cas, c'est encore pire).
L'idée est alors de baisser V en même temps que F, dans ce cas on y gagne (S baisse aussi).
La tache sera plus lente mais moins énergivore. Par contre, le problème est la latence pour changer de mode quand le besoin de puissance arrive. D'ou l'idée de gérer les latences dans une API j'imagine.
"La première sécurité est la liberté"