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.
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:24