Le "truc" amusant actuellement, c'est que le noyau Linux est tres mauvais a estime la bonne frequence et le nombre de CPU au bon moment. Les systemes de cpu idle et de cpu freq etant decouple du scheduler qui lui meme perd tout l'historique des qu'il bouge une tache sur un nouveau coeur. Le resultat actuel, c'est que le CPU se retrouve dans les taches graphiques souvent a la mauvaise frequence au mauvais moment.
La raison est simple, vous avez une serie de tache globalement plutot seriel, qui enchaine une etape IO bound, MEM bound, CPU bound, MEM bound, pour retourner en IO bound. Le tout par cycle de 16ms.
Le probleme est connu, et c'est pour cela qu'il y a du travail sur la gestion d'energie et le scheduler en cour. Mais cela affecte aussi l'user space. Le noyau n'a des statistiques que par process, il ne sait pas si un bout de code est IO, MEM ou CPU bound. Par contre, un process, a terme, il saura quel est potentiellement la frequence ideal de fonctionnement. Cela n'est vrai bien entendu que si dans un meme process ne tourne que des taches qui ont les meme proprietes !
Donc il faut bien s'orienter vers du multi thread, mais les mesures actuelles de consomation ne sont probablement pas tres pertinente tant que le noyau n'aura pas ete corrige.
Pour une explication potentielle du pourquoi, 2 * 50%, c'est mieux que 1 * 100%, c'est probablement lie a la disponibilites de plus de bande passante memoire du cache L1 (un par core) qui permet d'eviter des acces dans les sous systemes memoire plus lointain et plus couteux en energie pour y acceder (Acceder un registre etant moins energivore qu'un acces en L1, un L1 moins qu'un L2 et un L2 moins qu'un acces en RAM). C'est potentiellement une explication que je vois, surtout si la frequence des core est alors adapte a la consommation de bande passante memoire offert par le cache.
[^] # Re: Remarque à la c...
Posté par cedric . En réponse à la dépêche Servo fin 2015 : où en est-on ?. Évalué à 7.
Le "truc" amusant actuellement, c'est que le noyau Linux est tres mauvais a estime la bonne frequence et le nombre de CPU au bon moment. Les systemes de cpu idle et de cpu freq etant decouple du scheduler qui lui meme perd tout l'historique des qu'il bouge une tache sur un nouveau coeur. Le resultat actuel, c'est que le CPU se retrouve dans les taches graphiques souvent a la mauvaise frequence au mauvais moment.
La raison est simple, vous avez une serie de tache globalement plutot seriel, qui enchaine une etape IO bound, MEM bound, CPU bound, MEM bound, pour retourner en IO bound. Le tout par cycle de 16ms.
Le probleme est connu, et c'est pour cela qu'il y a du travail sur la gestion d'energie et le scheduler en cour. Mais cela affecte aussi l'user space. Le noyau n'a des statistiques que par process, il ne sait pas si un bout de code est IO, MEM ou CPU bound. Par contre, un process, a terme, il saura quel est potentiellement la frequence ideal de fonctionnement. Cela n'est vrai bien entendu que si dans un meme process ne tourne que des taches qui ont les meme proprietes !
Donc il faut bien s'orienter vers du multi thread, mais les mesures actuelles de consomation ne sont probablement pas tres pertinente tant que le noyau n'aura pas ete corrige.
Pour une explication potentielle du pourquoi, 2 * 50%, c'est mieux que 1 * 100%, c'est probablement lie a la disponibilites de plus de bande passante memoire du cache L1 (un par core) qui permet d'eviter des acces dans les sous systemes memoire plus lointain et plus couteux en energie pour y acceder (Acceder un registre etant moins energivore qu'un acces en L1, un L1 moins qu'un L2 et un L2 moins qu'un acces en RAM). C'est potentiellement une explication que je vois, surtout si la frequence des core est alors adapte a la consommation de bande passante memoire offert par le cache.