[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dual core: ne fonctionne pas ?



Gaëtan PERRIER wrote:
Le Sun, 8 Mar 2009 16:12:11 +0100
Sylvain Sauvage <Sylvain.Sauvage@metanoesis.net> a écrit:

  Ce n’est pas bizarre.
  Ce n’est pas un problème.

  Pour faire simple, prenez la question dans l’autre sens :
est-ce que ça vous plairait qu’un cœur surchauffe pendant que
l’autre se tourne les pouces ?

Donc si je te comprends bien dans le cas d'un programme monothread, ce
thread va passer d'un coeur à l'autre régulièrement pour répartir
l'échauffement? Je suppose que celà doit induire une (petite?) perte de
perf, non?
D'abord, je ne sais pas si ce saut d'un coeur à l'autre d'un thread/processus actif est fait exprès. (je pense que non).

Ensuite, les processeurs actuels sont prévus pour que tous leurs coeurs soient actifs (sinon, à quoi bon les concevoir avec plusieurs coeurs?).

Par contre, dans les utilisations embarquées [téléphone portable, PDA, MID] où la consommation d'énergie compte, on peut effectivement ne pas utiliser tous les coeurs pour diminuer la consommation (et les performances). Et j'ai déjà lu des papiers de recherche proposant un scheduler qui diminue ainsi l'échauffement d'une puce.

Sur les PC linuxiens, ce n'est pas un problème: le multi-coeur est conçu pour faire tourner tous les coeurs (et bien sûr chauffera plus dans ce cas).

Je ne pense pas que le transfert du processus actif d'un core à l'autre que tu observes soit voulu et prévu dans les schedulers actuels (pour la bonne raison que ce transfert est rare: tous les quelques secondes, ce qui est trop si on raisonne thermiquement).

Par contre, j'en vois une explication assez simple: le scheduler du noyau linux est préemptif, donc interrompt chaque tâche active (typiquement 300 fois par seconde; c'est réglable en recompilant le noyau). Et il peut se trouver q'un autre processus soit affecté sur le coeur que tu considères (typiquement l'utilitaire d'affichage de la courbe de charge); alors la tâche de compression se voit migrée sur l'autre coeur.

Cette migration de tâche d'un coeur à l'autre est très rapide à l'échelle humaine (quelques microsecondes) et je ne crois pas que ça influe sur les performances de manière mesurable (càd que j'imagine que la perte de performance est bien plus petite que quelques petites fractions de pour-mille).

Si un développeur a des raisons valables de vouloir coller une tâche sur un coeur (ce qui pourrait dégrader un peu les performances) il pourrait utiliser l'appel système sched_setaffinity (je ne m'en suis jamais servi).

Librement.

--
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***


Reply to: