Oui. Les processus et les threads du noyau sont répartis entre les processeurs. Ceux de l'espace utilisateur ne le sont pas.
Les versions 2.0 du noyau supportent les systèmes SMP de type hypersparc (SS20, etc...) et Intel 486, Pentium ou machines supérieurs compatible avec la norme Intel MP1.1/1.4. Richard Jelinek ajoute : jusqu'à présent, seul des systèmes ne comprenant pas plus de 4 processeurs ont été testés. La spécification MP (et donc Linux) autorise théoriquement jusqu'à 16 processeurs.
Le support SMP pour les architectures UltraSparc, SparcServer, Alpha et PowerPC est disponible dans le 2.2.x.
MIPS, m68k et ARM ne gèrent pas le SMP; les deux derniers ne le supporteront probablement jamais.
Ceci étant, je ferai un hack pour MIPS-SMP dès que j'aurais une machine SMP...
La plupart des distributions ne fournissent pas un noyau adapté au SMP.
Vous devrez donc en faire un vous même. Si vous n'avez encore jamais
compilé de noyau, voila une excellente occasion d'apprendre.
Expliquer comment compiler un nouveau noyau dépasse le
cadre de ce document; préférez-vous au Linux Kernel Howto pour de plus amples
informations (C. Polisher).
Dans la série 2.0 jusqu'à la version 2.1.132 exclue du noyau, décommentez la
ligne SMP=1 dans le Makefile principal (/usr/src/linux/Makefile).
Dans la version 2.2, configurez le noyau et répondez "oui" à la question "Symetric multi-processing support" (Michael Elizabeth Chastain).
Autorisez l'horloge temps réel en cochant l'option "RTC support" (Robert G. Brown). Notez qu'inclure le support RTC, en réalité, pour autant que je sache, n'empêche pas le problème connu de la dérive de l'horloge avec le SMP : activer cette fonctionnalité avertit en cas de lecture de l'horloge au démarrage. Une note de Richard Jelinek signale aussi qu'activer "Enhandced RTC" est nécessaire pour activer le deuxième processeur (identification) sur certaines cartes mère Intel exotiques.
Enfin, sur plate-forme Intel, N'ACTIVEZ PAS l'option APM (Advanced Power
Management)! APM et SMP sont incompatibles et votre système plantera
certainement (ou du moins probablement ;)) au démarrage si APM est
activé (Jakob Oestergaard).
Alan Cox le confirme : désactivez APM pour les machines SMP en
2.1.x. En gros le comportement APM est indéfini en présence de systèmes SMP et
tout peut arriver.
Toujours sur plate-forme Intel, activez "MTRR (Memory Type Range Register)
support". Certains BIOS sont défectueux et n'activent pas la mémoire cache du
second processeur. Le support MTRR contient le code pour y remédier.
Vous devez reconstruire votre noyau et vos modules quand vous passez en SMP
et quand vous changez de mode SMP. N'oubliez pas d'effectuer un
make modules et un make modules_install (Alan Cox).
Si vous obtenez des erreurs au chargement des modules, vous n'avez probablement pas réinstallé vos modules. Néanmoins, avec quelques noyaux 2.2.x, certains ont rapporté des problèmes lors de la recompilation d'un noyau SMP en noyau UP (Uni-Processeur). Afin de résoudre cela, sauvegardez votre fichier .config, et faites un make mrproper, restaurez votre fichier .config et recompilez votre noyau (make dep, etc...) (Wade Hampton). N'oubliez pas de relancer lilo après avoir recopié votre nouveau noyau.
Récapitulation :
make config # ou menuconfig ou xconfig make dep make clean make bzImage # ou ce que vous voulez # copiez l'image du noyau manuellement puis RELANCER LILO # ou make lilo make modules make modules_install
Dans la série 2.0, commentez la ligne SMP=1 dans le Makefile
principal (/usr/src/linux/Makefile).
Pour la série 2.2, configurez le noyau et répondez "no" à la question "Symmetric multi-processing support" (Michael Elizabeth Chastain).
Vous devez absolument recompiler votre noyau et ses modules pour activer
ou désactiver le mode SMP. N'oubliez pas de faire make modules,
make modules_install et de relancer lilo. Voyez les notes plus haut
sur les problèmes de configuration possibles.
cat /proc/cpuinfo
Sortie typique (bi-PentiumII):
processor : 0 cpu : 686 model : 3 vendor_id : GenuineIntel [...] bogomips : 267.06 processor : 1 cpu : 686 model : 3 vendor_id : GenuineIntel [...] bogomips : 267.06
La version 2.2 du noyau possède une gestion des signaux, des interruptions et de quelque E/S à verrouillage fin (fine grain locking). Le reste est en cour de migration. En mode SMP, plusieurs processus peuvent être ordonnancés simultanément.
Les noyaux 2.3 (futur 2.4) possèdent vraiment des verrous noyaux fins. Dans la série des noyaux 2.3 l'usage des gros blocages noyau a tout simplement disparu. Tous les sous-systèmes majeurs du noyau Linux sont complètement codés avec des threads : réseau, VFS, VM, ES, block/pages de cache, ordonnancement, interruptions, signaux, etc... (Ingo Molnar)
Oui et non. Il n'est pas possible de forcer l'assignation d'un processus à un processeur spécifique mais l'ordonnanceur Linux possède un parti-pris pour chaque processus qui tend à conserver les processus attachés à un processeur spécifique.
Oui. Voir PSET - Processor Sets for the Linux kernel:
Ce projet a pour but d'offrir une version compatible au niveau sources et fonctionnalités de pset (tel que défini par SGI - partiellement retiré de leur noyau 6.4 IRIX) pour Linux. Cela autorise les utilisateurs à déterminer sur quel processeur ou ensemble de processeurs un processus peut tourner. Les utilisations possibles incluent l'assignement de thread à des processeurs distincts, la synchronisation, la sécurité (un processeur dédié à `root') et sûrement davantage encore.
Nous nous sommes attachés à concentrer toutes les fonctionnalités autour de l'appel système sysmp(). Cette routine accepte un certain nombre de paramètres qui déterminent la fonctionnalité requise. Ces fonctions comprennent:
Signalez s'il vous plaît les bogues à linux-smp@vger.rutgers.edu.
Si vous voulez mesurer les performances de votre système SMP, vous pouvez essayer les tests de Cameron MacKinnon, disponibles à http://www.phy.duke.edu/brahma/benchmarks.smp.
Si vous vous le demandez, vous n'en avez probablement pas besoin. :)
En général les systèmes multiprocesseurs offrent de meilleurs
performances que les systèmes monoprocesseurs, mais pour obtenir un gain
quelconque vous devez considérer bien d'autres facteurs que le seul nombre
de processeurs. Par exemple, sur un système donné, si le processeur
est en général inactif, la plupart du temps à cause d'un disque dur
lent, alors le système est bloqué au niveau des entrées/sorties
("input/output bound"); il ne bénéficiera probablement pas de la puissance
d'un processeur supplémentaire. Si, d'un autre coté, un système doit exécuter
beaucoup de processus simultanément et que l'utilisation processeur est très
forte, alors vous êtes susceptible d'améliorer les performances de votre
système. Les disques dur SCSI peuvent être très efficaces en utilisation avec
plusieurs processeurs. Ils peuvent gérer plusieurs commandes simultanément
sans immobiliser le processeur (C. Polisher).
Tout dépend de l'application, mais généralement non. Le SMP implique
quelques "frais de gestion" absents d'une machine monoprocesseur.
(Wade Hampton).
:)
Grâce à Samuel S. Chessman, se ici trouvent quelques utilitaires pratiques :
http://www.cs.inf.ethz.ch/~rauch/procps.html
En gros, il s'agit de procps v1.12.2 (top, ps, et. al.) et de quelques patches pour le support SMP.
Pour les 2.2.x, Gregory R. Warnes a rendu disponible un patch à http://queenbee.fhcrc.org/~warnes/procps
xosview-1.5.1 supporte le SMP, les noyaux supérieurs au 2.1.85 (inclus) et l'entrée cpuX dans le fichier /proc/stat.
Page d'accueil officielle pour xosview : http://lore.ece.utexas.edu/~bgrayson/xosview.html
Vous ici trouverez une version patchée par Kumsup Lee pour les noyaux 2.2.p : http://www.ima.umn.edu/~klee/linux/xosview-1.6.1-5a1.tgz
Les différents patches noyau de Forissier sont disponibles à : http://www-isia.cma.fr/~forissie/smp_kernel_patch/
Néanmoins, vous ne pouvez pas contrôler l'ordonnancement de façon précise avec xosview car ce dernier le perturbe (H. Peter Anvin).
Utiliser :
# make [modules|zImage|bzImages] MAKE="make -jX"
où X = nombre maximum de processus.
Notez que ça ne marche pas avec "make dep".
Avec un noyau 2.2, référez vous au fichier
/usr/src/linux/Documentation/smp.txt pour des instructions précises.
Par exemple, comme lancer de multiples compilateurs autorise une machine avec
suffisamment de mémoire à utiliser le temps processeur autrement perdu
durant les délais causés par les E/S, make MAKE="make -j 2" -j 2
aide réellement même sur les machines monoprocesseurs.
(de Ralf Bächle).
time est-il
erroné ?
(de Joel Marchand)
Dans la série des 2.0, le résultat de la commande time est faux.
La somme utilisateur+système est juste *mais* 'l'étendue' entre le temps
utilisateur et le temps système est faux.
Plus précisément : "tout le temps passé sur un processeur autre que celui de démarrage est comptabilisé comme temps système. Si vous chronométrez un programme, ajoutez le temps utilisateur et le temps système. Votre mesure sera alors correcte, à ceci près qu'elle inclura aussi le temps système qui restera à décompter" (Jakob Østergaard).
Ce bogue est corrigé dans les versions 2.2.
Section par Jakob Østergaard.
Cette section a pour but de signaler ce qui fonctionne et ce qui ne fonctionne pas quand il s'agit de programmer des logiciels avec des threads pour Linux SMP.
Comme ni fork() ni les processus PVM/MPI ne partagent généralement la mémoire, mais communiquent au moyen d'IPC ou d'une API de messagerie, ils ne seront pas décrits davantage dans cette section. Ils ne sont pas vraiment spécifiques à SMP, puisqu'ils sont tout autant employés - sinon plus - avec des ordinateurs monoprocesseurs et des clusters.
Seuls les threads POSIX fournissent des threads multiples partageant certaines ressources telles la mémoire. Cette propriété des machines SMP autorise plusieurs processeurs à partager leur mémoire. Pour employer deux (ou plus ;) ) processeurs avec un système SMP, utilisez une librairie de thread du noyau. Une bonne librairie LinuxThreads, une librairie de thread écrite par Xavier Leroy est maintenant intégrée avec la glibc2 (aka libc6). Les distributions Linux récentes intègrent toutes cette librairie par défaut. Vous n'avez donc pas à obtenir un paquetage séparé pour utiliser les threads du noyau.
Il existe des mises en oeuvre des threads (et thread POSIX) de niveau application qui ne tirent pas avantage des threads du noyau. Ces paquetages gardent le thread dans un seul processus et, partant, ne profitent pas du SMP. Néanmoins, elles sont bonnes pour beaucoup d'applications et ont tendance à être plus rapides que les threads du noyau sur des systèmes monoprocesseurs.
Le multithreading n'a jamais été vraiment populaire dans le monde UN*X. Pour diverses raisons, les applications exigeant de multiples processus ou threads ont été pour la plupart écrites en utilisant fork(). Donc, avec une approche de type threads, on rencontre des problèmes d'incompatibilités et de non-adaptation aux thread des librairies, compilateurs et débogueurs. GNU/Linux n'y fait pas exception. Espérons que les sections qui suivent apporteront quelques lumières sur ce qui est possible et sur ce qui ne l'est pas.
Les vieilles librairies ne sont pas sûres au niveau des threads. Il est très important que vous utilisiez la GNU libc (glibc), aussi connue sous le nom de libc6. Vous pouvez évidemment utiliser des versions antérieurs, mais cela vous causera plus de problèmes que mettre à jour votre système. Enfin, probablement :)
Si vous voulez utiliser GDB pour déboguer vos programmes, voyez plus bas.
Il existe de nombreux langages de programmation disponibles pour GNU/Linux et beaucoup d'entre eux utilisent les threads d'une manière ou d'une autre. Certains langages comme Ada et Java incluent même les threads dans les primitives du langage.
Cette section, pour l'instant, ne décrira que le C et le C++. Si vous avez une expérience de programmation SMP avec d'autre langages, merci de nous en faire part.
Les compilateurs GNU C et C++, tout comme EGCS C et C++, fonctionnent avec le support thread de la librairie C standard (glibc). Il y a néanmoins quelques problèmes :
Le débogueur GNU GDB, à partir de la version 4.18, devrait prendre en charge les threads correctement. La plupart des distributions Linux comprennent une version patchée de gdb qui gère les threads.
Il n'est pas nécessaire de patcher la glibc pour qu'elle fonctionne avec des threads. Si vous n'avez pas besoin de déboguer le logiciel (cela peut-être vrai pour toutes les machines qui ne sont pas dédiées au développement), il n'y a pas besoin de patcher la glibc.
Notez que les core-dumps ne sont d'aucune utilité quand vous utilisez des threads. D'une manière ou d'une autre, le core dump est attaché au thread courant et non au programme tout entier. Aussi, pour déboguer quoi que ce soit, faites le depuis le débogueur.
Astuce : si vous avez un thread qui perd la tête, se met à utiliser 100% du temps CPU et que vous ne voyez pas pourquoi, voici une méthode élégante de trouver ce qui se passe : lancez le programme depuis la ligne de commande, sans GDB. Faites dérailler votre thread. Utilisez top pour obtenir le PID du processus. Lancez GDB tel que gdb program pid. GDB s'attachera lui-même au processus dont vous avez spécifié le PID et arrêtera le thread. Vous disposez maintenant d'une session GDB avec le thread incriminé et vous pouvez utiliser bt ou d'autres commandes pour suivre ce qui se passe.
ElectricFence : cette librairie n'est pas sûre du point de vue SMP. Il devrait néanmoins être possible de la faire fonctionner dans un environnement threadé en insérant des verrous dans son code source.
Voyez Linux Parallel Processing HOWTO
Beaucoup d'informations utiles se trouvent sur Parallel Processing using Linux
Voyez aussi Linux Threads FAQ
Oui. Pour les programmes vous devriez regarder à
Multithreaded programs on linux (j'adore les
liens hypertextes, le saviez vous ? ;))
En ce qui concerne les librairies :
Grâce à David Buccarelli, andreas Schiffler et Emil Briggs, il existe une version multithread (à l'heure actuelle [1998-05-11], une version fonctionne et permet d'obtenir un accroissement de 5-30% avec certaines suites de test OpenGL). La partie multithread est maintenant incluse dans la distribution Mesa officielle comme une option expérimentale. Pour plus d'information, voyez Mesa library
BLAS et FFTs optimisés Pentium pro pour Intel Linux
Les routines multithread BLAS ne sont pas disponibles pour l'instant, mais une librairie multithread est prévue pour 1998-05-27, voir Blas News pour plus de détails.
Emil Briggs, la même personne qui est impliquée dans la version multithread de MESA, est aussi en train de travailler sur la version multithread des plugins de The Gimp. Voyez http://nemo.physics.ncsu.edu/~briggs/gimp/index.html pour plus d'info.