Si tu baisses la fréquence, tu augmentes le temps pour une tache,
Uniquement si tu as un seul coeur et que ta tache n'est pas divisible sur plusieurs coeurs !
J'ai même lu une étude, ou il baissait la fréquence cpu ou celle du bus mémoire en fonction de la charge qui était cpu bound ou memory bound, il gagnait 10% de consommation.
Etude mono-coeur probablement. Mais bon, il faut voir que le noyau et les applications ne communiquent aussi pas assez sur le sujet pour prendre une bonne decision. Si tu as des threads qui vont etre CPU bound, faut reveiller toutes tes cores le plus vite possible (Pas de warmup comme avec l'ordonnanceur classique de linux). Puis tu reajustes la frequence a la baisse en fonction de ton package de temperature et de l'utilisation reelle du CPU.
Par contre, si tu as des threads IO bound, tu te reveilles tranquille avec un warmup. Meme avec la frequence la plus basse, tu vas avoir de tres bonne perfs (energie et temps pour le resultat) et tu augmentes progressivement jusqu'a ce que cela ne serve a rien. C'est la logique qui est globalement utilise par le noyau actuellement.
Si tu as des threads memory bound, tu reveille un coeur a pleine frequence et tu ajustes progressivement si necessaire pour avoir le resultat qui maximise la bande passante et l'usage d'un coeur.
Bon, ca c'est simple... Maintenant tu mixes des threads de toutes les categories dans le meme systeme et pour etre plus sympa tu ne dis pas qui fait quoi au kernel ! Bien entendu le resultat est globalement mauvais. C'est un des changements que j'aimerais bien voir arriver a un moment dans le kernel, la possibilite de dire si un thread est CPU, IO ou memory bound. Avec ca le scheduler pourrait prendre des decisions plus efficace pour eviter d'avoir des frame drop et une surconsomation d'energie. Par contre, c'est des problematiques bas niveau et il faut que toute la chaine coopere.
Cela demande aussi de diviser tes taches intelligement en plusieurs thread pour que kernel puisse prendre la bonne decision de scheduling (globalement equilibre les taches entre les processeurs et ajuster la frequence a la volee).
Sinon les processeurs que j'utilise sont parfaitement capable d'ajuster la frequence de toute la puce, sous systeme memoire inclue. Ca fait d'ailleur partie des points de mesure en premiere approximation de la consomation d'energie de deux logiciels qui font la meme chose. D'ailleurs ils ont des fonctions sympa, comme la possibilite de couper l'alimentation complete d'un banc de memoire pour sauver de l'energie. Ca veut dire qu'il faut bouger tout le monde pour ne pas perdre les donnees, mais c'est payant si ton soft est optimise pour ne pas utiliser trop de memoire et avoir des grandes periodes de veille
La strategie etant d'attendre un peu, de signaler aux applications qu'on va partir en veille profonde donc qu'elles doivent vider leur cache et compresser leurs objets ou juste se succider. Puis on peut commencer a bouger les pages d'un banc a l'autre, probablement que l'utilisation de zswap peut aider dans ce scenario. Enfin on peut peut etre couper un banc memoire complet et partir en suspend. Sachant que en suspend, la memoire est le second point de consomation (derriere la radio), c'est une optimisation assez sympa, surtout sur les telephones qui passe leur temps en suspend dans la poche.
[^] # Re: Mouais
Posté par cedric . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 5.
Uniquement si tu as un seul coeur et que ta tache n'est pas divisible sur plusieurs coeurs !
Etude mono-coeur probablement. Mais bon, il faut voir que le noyau et les applications ne communiquent aussi pas assez sur le sujet pour prendre une bonne decision. Si tu as des threads qui vont etre CPU bound, faut reveiller toutes tes cores le plus vite possible (Pas de warmup comme avec l'ordonnanceur classique de linux). Puis tu reajustes la frequence a la baisse en fonction de ton package de temperature et de l'utilisation reelle du CPU.
Par contre, si tu as des threads IO bound, tu te reveilles tranquille avec un warmup. Meme avec la frequence la plus basse, tu vas avoir de tres bonne perfs (energie et temps pour le resultat) et tu augmentes progressivement jusqu'a ce que cela ne serve a rien. C'est la logique qui est globalement utilise par le noyau actuellement.
Si tu as des threads memory bound, tu reveille un coeur a pleine frequence et tu ajustes progressivement si necessaire pour avoir le resultat qui maximise la bande passante et l'usage d'un coeur.
Bon, ca c'est simple... Maintenant tu mixes des threads de toutes les categories dans le meme systeme et pour etre plus sympa tu ne dis pas qui fait quoi au kernel ! Bien entendu le resultat est globalement mauvais. C'est un des changements que j'aimerais bien voir arriver a un moment dans le kernel, la possibilite de dire si un thread est CPU, IO ou memory bound. Avec ca le scheduler pourrait prendre des decisions plus efficace pour eviter d'avoir des frame drop et une surconsomation d'energie. Par contre, c'est des problematiques bas niveau et il faut que toute la chaine coopere.
Cela demande aussi de diviser tes taches intelligement en plusieurs thread pour que kernel puisse prendre la bonne decision de scheduling (globalement equilibre les taches entre les processeurs et ajuster la frequence a la volee).
Sinon les processeurs que j'utilise sont parfaitement capable d'ajuster la frequence de toute la puce, sous systeme memoire inclue. Ca fait d'ailleur partie des points de mesure en premiere approximation de la consomation d'energie de deux logiciels qui font la meme chose. D'ailleurs ils ont des fonctions sympa, comme la possibilite de couper l'alimentation complete d'un banc de memoire pour sauver de l'energie. Ca veut dire qu'il faut bouger tout le monde pour ne pas perdre les donnees, mais c'est payant si ton soft est optimise pour ne pas utiliser trop de memoire et avoir des grandes periodes de veille
La strategie etant d'attendre un peu, de signaler aux applications qu'on va partir en veille profonde donc qu'elles doivent vider leur cache et compresser leurs objets ou juste se succider. Puis on peut commencer a bouger les pages d'un banc a l'autre, probablement que l'utilisation de zswap peut aider dans ce scenario. Enfin on peut peut etre couper un banc memoire complet et partir en suspend. Sachant que en suspend, la memoire est le second point de consomation (derriere la radio), c'est une optimisation assez sympa, surtout sur les telephones qui passe leur temps en suspend dans la poche.