Oui. Les processus et les threads du noyau sont repartis entre les processeurs. Ceux de l'espace utilisateur ne le sont pas.
Dans le 2.0, les systèmes SMP supportés sont les 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 jusque que 4 processeurs ont été testé et la norme 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 support pas SMP; les deux derniers ne le supporteront probablement jamais.
Cela dit, je ferai un hack pour MIPS-SMP aussitôt que j'aurais une machine SMP ...
La plupart des distributions ne fournissent pas un noyau adapter au SMP, cela signifie que vous devrez le faire vous même. Si vous n'avez encore jamais compiler votre propre noyau, c'est une excellente raison pour apprendre comment cela se fait. Expliquer comment compiler un nouveau noyau dépasse le but de ce document; se référer vous au Linux Kernel Howto pour de plus ample information. (C. Polisher)
Dans la série 2.0 jusque 2.1.132 exclu du noyau, décommenter 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 "Symmetric multi-processing support" (Michael Elizabeth Chastain).
ET
autoriser l'horloge temps réel en cochant l'item "RTC support" (de Robert G. Brown). Notez qu'inclure le support RTC, en réalité, autant que je sache, n'empêche pas le problème connu de la dérive de l'horloge avec le SMP mais activer cette fonctionnalité prévient quand l'horloge est lue au démarrage. Une note de Richard Jelinek dit aussi qu'activer "Enhandced RTC" est nécessaire pour activer le deuxième processeur (identification) sur certaines cartes mère Intel originales.
ET
(noyau x86) NE PAS activer APM (advanced power management)! APM et SMP
ne sont pas compatibles, et votre système plantera certainement (ou moins
probablement ;)) au démarrage si APM est activer
(Jakob Oestergaard).
Alan Cox confirme cela : 2.1.x désactiver APM pour les machines SMP.
En gros le comportement APM est indéfini en présence de systèmes SMP, et tout
peut advenir.
ET
(noyau x86) activer "MTRR (Memory Type Range Register) support". Certains BIOS sont bogué, ils n'activent pas la mémoire cache du second processeur. Le support MTRR contient le code qui résout de tels problèmes.
Vous devez reconstruire votre noyau et vos modules quand vous passer en SMP
et quand vous changer de mode SMP. N'oubliez pas de faire make modules
et make modules_install (de 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, des gens ont reporté 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 faite make mrproper, restaurer votre fichier .config, puis recompiler votre noyau (make dep, etc.) (Wade Hampton). N'oubliez pas de relancer lilo après avoir recopier 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, commenter la ligne SMP=1 dans le Makefile
principal (/usr/src/linux/Makefile).
Pour la série 2.2, configurer le noyau et répondez "no" à la question "Symmetric multi-processing support" (Michael Elizabeth Chastain).
Vous devez absolument recompiler votre noyau et ses modules quand vous
changer vers ou d'un mode SMP. N'oubliez pas de faire make modules
et make modules_install et de lancer lilo. Voyez les notes plus haut
sur les problèmes possibles de configuration.
cat /proc/cpuinfo
Sortie typique (double 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 quelque E/S à blocage 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ède vraiment des blocages noyau fins. Dans la série des noyaux 2.3 l'usage des gros blocages noyau a tout simple disparut, tous les sous-systèmes majeurs du noyau Linux sont complètement coder 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 prit pour chaque processus, qui tend à conserver les processus attacher à un processeur spécifique.
Oui. Voir PSET - Processor Sets for the Linux kernel:
Le but de ce projet est de faire une version équivalent compatible au niveau source et fonctionnalité 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 assignement de thread à des processeurs distincts, synchronisation, sécurité (un processeur `root' dédier ?) et sûrement plus.
Nous nous sommes attachés à concentrer toutes les fonctionnalités autour de l'appel système sysmp(). Cette fonction prend un certain nombre de paramètres qui déterminent quelle fonction est requise. Ces Fonctions comprennent:
S'il vous plaît rapportez 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 demandez, c'est que vous n'en avez probablement pas
besoin. :)
Généralement, les systèmes multiprocesseurs offrent de meilleurs
performance que les systèmes monoprocesseurs, mais pour obtenir un gain
quelconque vous devez considérer beaucoup d'autres facteurs que le nombre
de processeur. 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 ce système est "entrée/sortie limitée" ("input/output bound"),
et 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és, et 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 utilisés avec de multiple
processeurs, grâce à la façon dont ils peuvent gérer de multiples commandes
sans immobiliser le processeur.(C. Polisher)
Cela dépend de l'application, mais généralement non. Le SMP implique
quelques "frais de gestion" qu'une machine monoprocesseur n'a pas.
(Wade Hampton).
:)
Merci à Samuel S. Chessman, ici se trouvent quelques utilitaires pratiques:
http://www.cs.inf.ethz.ch/~rauch/procps.html
En gros, c'est procps v1.12.2 (top, ps, et. al.) et 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. Et les noyaux supérieurs au 2.1.85 (inclus) l'entrée cpuX dans le fichier /proc/stat.
La page d'accueil officielle pour xosview est: http://lore.ece.utexas.edu/~bgrayson/xosview.html
Ici vous trouverez une version patchée par Kumsup Lee pour les noyaux 2.2.x : 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 précisément avec xosview, car xosview produit une perturbation de l'ordonnancement lui même. (H. Peter Anvin)
utiliser:
# make [modules|zImage|bzImages] MAKE="make -jX"
où X = nombre maximum de processus.
ATTENTION: Cela 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 spécifiques.
BTW, 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 erroné ?
(de Joel Marchand)
Dans la série des 2.0, le résultat rendu par 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: "L'explication est que tout le temps passer sur un processeur autre que celui de démarrage est comptabiliser comme temps système. Si vous chronométrer un programme, ajoutez le temps utilisateur et le temps système, alors votre chronométrage sera à peu près juste, à ceci près qu'il inclut aussi le temps système qui est à peu près juste, à ceci près qu'il inclut le temps système qui est correctement décompter" (Jakob Østergaard).
Ce bogue est corrigé dans les 2.2.
Section par Jakob Østergaard.
Cette section a pour but de souligner ce qui marche, et ce qui ne marche pas quand il s'agit de programmer des logiciels avec de multiples threads pour SMP Linux.
Comme ni fork(), ni les processus PVM/MPI ne partagent généralement pas la mémoire, mais communiquent au moyen d'IPC ou d'une API de messagerie, ils ne seront pas décrit plus avant dans cette section. Ils ne sont pas très spécifiques à SMP, puisqu'ils sont employés autant - voir plus - sur des ordinateurs monoprocesseurs et des clusters de ceux-ci.
Seul les threads POSIX nous fournissent des threads multiples partageant les ressources comme - particulièrement - la mémoire. C'est cette capacité qui fait des machines SMP leur particularité, autoriser plusieurs processeurs à partager leur mémoire. Pour employer deux (ou plus ;) processeurs d'un système SMP, utilisez une librairie de thread du noyau. Une bonne librairie est LinuxThreads, une librairie de thread écrite per Xavier Leroy qui 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 implémentations des threads (et thread POSIX) qui sont de niveau application, et ne tirent pas avantage des threads du noyau. Ces paquetages gardent le thread dans un seul processus, et par-là ne tirent pas avantage du SMP. Néanmoins, elles sont bonnes pour beaucoup d'application et ont tendance à être plus rapide que les threads du noyau sur des systèmes monoprocesseurs.
Le multi-threading n'a jamais été vraiment populaire dans le monde UN*X. Pour quelques raisons, les applications exigeant de multiple processus ou thread, ont été pour la plupart écrite en utilisant fork(). Donc, en utilisant l'approche des threads, certain rencontre des problèmes d'incompatibilités (de non-adaptation aux thread des) librairies, compilateurs et debogueurs. GNU/Linux ne fait pas exception à cela. Espèront que les quelques prochaines sections apporteront une petite lumière sur ce qui possible et ce qui ne l'est pas.
Les vieilles librairies ne sont pas sures au niveau 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 de mettre à jour votre système, enfin probablement :)
Si vous voulez utiliser GDB pour déboguer vos programmes, voyer plus bas.
Il y a une grande quantité de langage de programmation disponible sous GNU/Linux, et beaucoup d'entre eux utilisent les threads d'une manière ou d'une autre (certains langages comme Ada et Java possède même les threads dans les primitives du langage).
Cette section, toutefois, en ce moment, ne décrira que le C et le C++. Si vous avez de l'expérience en programmation SMP avec d'autre langages, S'il vous plaît éclairez nous.
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 GNU Débogueur GDB à partir de 4.18, devrait prendre en main les threads correctement. La plupart des distributions Linux offrent une version patchée de gdb pour prendre en compte les threads.
Il n'est pas nécessaire de patcher la glibc dans le but de la faire fonctionner 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ée 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 utilisé de multiple threads. D'une manière ou d'une autre, le core dump est attaché aux thread courant, et non au programme tout entier. Aussi, quand vous déboguer quelque chose, faite le du débogueur
Astuce: Si vous avez un thread qui perd la tête, comme utiliser 100% du temps CPU, et que vous semblez ne pas pouvoir deviner pourquoi, voici une belle manière de trouver ce qui se passe: lancez le programme depuis la ligne de commande, sans GDB. Faites perdre la tête à votre thread. Utilisez top pour obtenir le PID du processus. Lancez GDB tel que gdb program pid. Cela fera GDB s'attacher lui-même au processus dont vous avez spécifier le PID, et arrêter le thread. Vous avez maintenant une session GDB avec le thread offensant, et pouvez utiliser bt ou d'autre pour voir ce qui arrive.
ElectricFence: Cette librairie n'est pas sure du point de vue SMP Il devrait être possible, néanmoins, de la faire fonctionner dans un environnement en insérant des verrous mutex dans le code d'ElectricFence.
Voyez Linux Parallel Processing HOWTO
Beaucoup d'informations utiles peuvent être trouvé à 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, il y a:
Merci à David Buccarelli, andreas Schiffler et Emil Briggs, il existe une version multithread (à l'heure actuelle [1998-05-11], il y a une version qui fonctionne et permet d'obtenir un accroissement de 5-30% avec certaine suite de test (benchmarks) 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é 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 impliquer 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.