David.Mentre@irisa.fr Linux fonctionne sur les machines SMP (Symetric Multi-Processors). Le support SMP fut introduit dans la version 2.0 du noyau et a �t� largement am�lior� depuis. La gestion est beaucoup plus fine dans la s�rie 2.2.x que dans la 2.0.x, d'o� de meilleures performances lorsque les processus font appel au noyau !
HOWTO maintenu par David Mentr� ( David.Mentre@irisa.fr). La derni�re version de ce HOWTO peut �tre obtenue �
Si vous voulez contribuer � ce HOWTO, je pr�f�re les diffs
SGML version de ce
document, mais toute remarque (en texte pur) sera grandement appr�ci�.
Si vous m'envoyez un e-mail � propos de ce document, ins�rez s'il vous pla�t
un tag tel [Linux SMP HOWTO] dans le champ Suject: de votre
e-mail. �a m'aide � trier automatiquement mon courrier (et vous recevrez
une r�ponse plus rapide ;)).
Ce HOWTO reprend et enrichit first draft �crit par Chris Pirih.
Toutes les informations contenues dans ce HOWTO sont fournies "tel que". Toute garantie explicite, implicite ou l�gale, concernant l'exactitude de l'information, de la convenance � quelque usage particulier est par la pr�sente sp�cifiquement d�clin�e. Alors que tous les efforts ont �t� faits pour assurer l'exactitude des informations contenues dans ce HOWTO, les auteurs n'assument aucune responsabilit� pour les erreurs, omissions ou dommages r�sultant de l'utilisation des informations contenues dans ce document.
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.
R�ponse courte: non.
R�ponse longue Intel r�vendique la propri�t� sur les plan APIC SMP, et tant qu'une compagnie ne prend pas de licence d'Intel pour cela, ils ne peuvent pas l'utiliser. Aucune compagnie ne l'a fait pour l'instant. Cela peut �videment changer dans le futur. A titre anecdotique, Cyrix et AMD adh�rent au standard non-propri�taire OpenPIC SMP mais actuellement il n'existe pas de carte m�re l'utilisant.
Mettez le en mode compatibilit� MP1.1/1.4.
V�rifiez "Configure Hardware" -> "View / Edit details" -> "Advanced mode" (F7 je pense) pour les options de configuration "APIC mode" et cochez "full Table mode". Il s'agit d'une recommandation officielle de Compaq (Daniel Roesen).
Adrian Portelli :
De Robert Hyatt: ALR Revolution quad-6 semble � peu pr�s s�re, alors que quelques machines Revolution quad plus vieilles sans processeurs P6 ne semble pas "fiables"...
De Alan Cox: si un de vos processeurs rapporte une valeur bogomips tr�s basse, son cache n'est pas activ�. Votre vendeur vous � probablement fournis un BIOS bogu�. Obtenez un patch pour contourner cela ou mieux retournez la � votre vendeur et achetez une carte m�re chez un fournisseur comp�tent.
Un noyau 2.0 (> 2.0.36) contient un patch MTRR qui devrait r�soudre ce probl�me (s�lectionnez l'option "handle buggy SMP BIOSes with bad MTRR setup" dans le menu "General setup").
Je pense que les BIOS SMP bogu�s sont pris en charge automatiquement dans les derniers noyaux 2.2.
Certaines machines IBM poss�dent le bloc BIOS MP1.4 dans l'EBDA. C'est autoris� mais pas support� en dessous des noyaux 2.2.
Il y a une vieille machine IBM SMP bas�e sur des 486SLC. Linux/SMP requiert un support FPU mat�riel.
Non (selon Alan :) ), 1.4 est juste une sp�cification plus stricte de 1.1.
Il s'agit d'un probl�me connu avec la gestion des IRQ et les blocages noyau longs dans la s�rie 2.0 des noyaux. Pensez � mettre � jour votre syst�me vers un 2.2 plus r�cent.
De Jakob Oestergaard: ou pensez � utiliser xntpd. Cela devrait garder votre horloge � l'heure. Je pense avoir entendu qu'activer RTC dans le noyau corrigeait aussi le probl�me de d�rive de l'horloge. �a a march� pour moi, mais j'ignore si cela est g�n�ral ou si j'ai juste �t� chanceux !
Certaines corrections du noyau dans les derniers 2.2.x devraient r�soudre ce probl�me.
Le num�ro du processeur est fix� par le fabricant de la carte m�re et ne veut absolument rien dire. Ignorez le.
(Doug Ledford) Essayez de recompiler LILO avec le support LARGE_EBDA et faites attention � bien toujours utiliser bzImage quand vous compilez le noyau. Cela semble avoir r�solu le probl�me de plantage au d�marrage ici sur une carte m�re Intel multi-Xeon. Notez cependant que cela semble aussi affecter LILO en ceci que l'option root= ne fonctionne plus. Faites donc bien attention d'avoir appliqu� 'rdev' � votre noyau au moment o� vous lancerez LILO afin d'�tre sur que votre noyau charge correctement le syst�me de fichier racine au d�marrage.
(Robert M. Hyatt) Avec 3 processeurs, avez-vous un terminateur dans le 4�me emplacement ?
Essayez l'option de d�marrage "noapic" (John Aldrich) et/ou "reboot=bios" (Terry Shull).
Essayez le dernier noyau 2.2.x et le patch knfsd. Cela est en cours d'investigation. (Wade Hampton)
Si vous utilisez les noyaux 2.2.11 ou 2.2.12, r�cup�rez le dernier noyau. Par exemple 2.2.13 poss�de de nombreuses corrections SMP. Plusieurs personnes ont rapport� ces noyaux comme instables pour le SMP. Ces m�mes noyaux peuvent avoir des probl�mes NFS qui provoqueraient des blocages. Aussi, utilisez une console s�rie pour capturer vos messages oops. (Wade Hampton)
Si le probl�me persiste (et que les suggestions sur cette liste n'ont pas aid� davantage), vous devriez alors essayer les derniers noyaux 2.3. Ils ont un code SMP/APIC plus bavard (et plus robuste) et un code de pr�vention contre les blocages durs qui produit des oops plus significatifs au lieu de planter en silence (Ingo Molnar).
(Osamu Aoki) Vous DEVEZ aussi d�sactiver toutes les fonctionnalit�s du BIOS li�es � l'�conomie d'�nergie. Exemple d'une bonne configuration (Dual Celeron 466 Abit BP6) :
POWER MANAGEMENT SETUP. ACPI: Disabled POWER MANAGEMENT: Disabled PM CONTROL by APM: No
(item par Wade Hampton)
Un bon moyen de d�boguer les blocages consiste � se procurer le patch ikd de Andrea Arcangeli: ftp://ftp.suse.com/pub/people/andrea/kernel-patches
Il y a plusieurs options de d�bogage. N'utilisez PAS l'option de blocage
logicielle ! Pour des machines SMP r�centes, activez l'option kernel debugging
et ensuite l'option NMI oopser. Afin de v�rifier que le NMI oopser fonctionne,
apr�s avoir d�marr� avec votre nouveau noyau, ex�cutez un
/cat /proc/interrupts et v�rifiez que vous obtenez des NMI.
Quand la machine se bloque, vous devriez obtenir un oops.
Vous pouvez aussi essayer l'option %eip. Elle autorise le noyau � �crire sur la console l'adresse %eip � chaque fois qu'une fonction du noyau est appel�e. Quand la machine se bloque, �crivez sur un papier la premi�re colonne ordonn�e selon la seconde colonne et cherchez ensuite les adresses dans le fichier System.map. Ca ne marche qu'en mode console.
Notez que l'utilisation d'une console s�rie facilite grandement le d�bogage des blocages noyau, qu'ils soient SMP ou non !
Un message comme:
APIC error interrupt on CPU#0, should never happen. ... APIC ESR0: 00000002 ... APIC ESR1: 00000000
Dans cette section vous trouverez quelques information sur les causes possibles de plantage sur une machine SMP (merci � Jakob �stergaard pour cette partie). Autant que je sache (David), les probl�mes �voqu�s ici sont sp�cifiques aux plate-formes Intel.
De Ralf B�chle: (concernant la taille des bo�tiers et les ventilateurs) il est important que l'air circule. Bien s�r, ce n'est pas possible quand toutes sortes d'obstacles, tels des c�bles, l'en emp�chent dans des bo�tiers par trop exigus. D'un autre c�t�, j'ai vu des bo�tiers surdimensionn�s provoquer de gros probl�mes. Il existe des bo�tiers au format tour sur le march� qui s'av�rent actuellement pire � rafra�chir que des bo�tiers au format bureau. En bref, la meilleure chose � faire est de penser � l'a�rodynamique dans le bo�tier. Des bo�tiers suppl�mentaires pour les p�riph�riques d�gageant de la chaleur sont �galement utiles.
Bien s�r vous pouvez toujours aller chez Radio Shack (ou similaire) et acheter un ventilateur. Vous pouvez utiliser lm_sensor pour surveiller la temp�rature des processeurs PII et PIII. Cela peut vous aider � d�terminer si la chaleur est un probl�me ou non (Wade Hampton).
N'achetez pas de la RAM bon march� et ne m�langez pas des barrettes diff�rente sur une m�me carte m�re.
Les cartes m�res Tyan sont tout particuli�rement connues pour leur susceptibilit� sur la vitesse de la RAM (voir le paragraphe ci-dessous sur Tyan pour une solution �ventuelle).
Il y a eu des rapports sur des m�moire RAM PC 100 � 10ns vendues avec des cartes m�res dont le processeur avait vraiment besoin de RAM � 8ns (Wade Hampton).
V�rifiez /proc/cpuinfo pour voir si vos processeurs fonctionnent � la
m�me cadence.
D'ailleurs, m�me s'il est stable, ne le surcadencez pas.
De Ralf B�chle: le surcadencement pose des probl�mes tr�s subtils. J'ai un bel exemple: une de mes vieilles machines surcadenc�es commet des erreurs de calcul pour quelques pixels d'une fractale de 640 X 400. Le probl�me est seulement visible quand on les compare en utilisant des outils. Le mieux est donc de ne jamais, never, nuncas, niemals surcadencer.
Les noyaux 2.0.x sur des syst�mes Ethernet rapide et hautes performances ont des probl�mes significatifs (et connus) avec les conditions de course/inter-blocage (race/deadlock) dans la prise en charge des interruptions r�seau.
La solution consiste � obtenir la derni�re version des pilotes 100BT en cours de d�veloppement � CESDIS Linux Ethernet device drivers site (ceux qui sont au point d�finissent SMPCHECK).
Si votre syst�me utilise le chipset 440FX alors les probl�mes de blocage sont peut-�tre d�s � une erreur (document�e) du chipset. En voici la r�f�rence:
Intel 440FX PCIset 82441FX (PMC) et 82442FX (DBX) Specification Update. pg. 13
http://www.intel.com/design/pcisets/specupdt/297654.htm
Le probl�me peut se r�soudre avec un contournement par le BIOS (ou un patch du noyau). David Wragg a �crit un patch qui est inclus dans le patch MTRR de Richard Gooch's. Pour plus d'informations ainsi qu'un descriptif de solution, voyez ici:
De Mark Duguid, R�gle implicite #1 avec une carte m�re W6LI. ;)
Parfois, certaines cartes ne sont pas reconnues ou peuvent d�clencher des conflits d'IRQ. Essayez de mettre les cartes sur des slots diff�rents et si possible de les assigner � des IRQ diff�rentes.
Contribution de hASCII : enlever la ligne "append="hisax=9,2,3" dans lilo.conf autorisant � utiliser un noyau de la s�rie 2.1.xx avec le support ISDN + Hisax activ�. Les noyaux de la s�rie 2.0.xx ne posent pas ce genre de probl�me.
Essayez aussi de configurer les option de configuration du BIOS comme "MP 1.4 mode" ou "route PCI interrupts through IOAPIC" ou "OS Type" configur� ni pour DOS ni pour Novell (Ingo Molnar).
Si vous bloquez alors que vous essayez d'acc�der au lecteur de disquettes
(par exemple pendant que du son est jou�) vous devriez peut-�tre �diter
le fichier drivers/pci/quirks.c et positionner
/int isa_dma_bridge_buggy = 1;. Le probl�me se manifeste avec mon Dell
WS400 dual PII/300, 2.2.x, SMP (Wade Hampton).
Notez que des informations plus pr�cises peuvent �tre trouv�es avec la liste des Cartes m�re suppos�es fonctionner sous Linux SMP
(St�phane �colivet)
Les machines SMP Linux les moins ch�res avec des processeurs disponibles de nos jours sont les syst�mes double Celeron. Un tel syst�me n'est pas officiellement possible selon Intel. On a int�r�t � v�rifier qu'il s'agit bien de Celerons de seconde g�n�ration, ceux avec 128 Kb de cache L2.
R�ponse officielle d'Intel : non, le Celeron ne peut pas fonctionner en mode SMP.
R�ponse pratique : c'est possible, mais cela demande une modification mat�rielle pour les processeurs Slot 1. La manipulation est d�crite par Tomohiro Kawada sur sa page Dual Celeron System. Naturellement, de telles modifications annulent la garantie... Certaines versions du processeur Celeron sont aussi disponibles au format Socket 370. Dans ce cas, l'alt�ration peut-�tre faite sur l'adaptateur Socket 370 � Slot 1 qui peut m�me �tre vendu pr�-cabl� pour une utilisation SMP (Andy Poling, Hans - Erik Skyttberg, James Beard).
Il existe aussi une carte m�re (ABIT BP6) autorisant l'insertion de deux Celerons dans le format Socket 370 (Martijn Kruithof, Ryan McCue), l'ABIT Computer BP6 v�rifi�e, test�e et support�e sous linux avec deux ppga socket 370 (Andre Hedrick).
Bien, merci.
Cela peut marcher. N�anmoins, surcadencer un tel syst�me n'est pas aussi facile que pour un monoprocesseur. Ce n'est franchement pas une bonne id�e pour un syst�me de production. Pour une utilisation personnelle, des syst�mes double Celeron 300 A fonctionnant parfaitement � 450 MHz ont �t� signal�s (de nombreuses personnes).
C'est impossible. Les processeurs Celerons poss�dent � peu pr�s les m�mes fonctionnalit�s qu'un Pentium II basique. Si vous voulez plus de deux processeur dans votre syst�me, vous devriez regarder du c�t� des machines � base de Pentium Pro, Pentium II Xeon ou Pentium III (?).
Un syst�me utilisant un Celeron "r�-autoris�" et un Pentium II � la m�me cadence peut th�oriquement fonctionner.
Alexandre Charbey � fabriqu� un tel syst�me:
Citation de la page web UltraLinux (syst�mes SMP seulement):
UltraLinux a fonctionn� sur une machine de 14 processeurs (voir la sortie dmesg).
(David Miller) Il ne devrait pas y avoir d'inqui�tudes.
Le seul probl�me connu et que nous n'avons pas l'intention de corriger, consiste en ce qu'un noyau SMP compil� pour des syst�mes 32bits (ie. non-ultrasparc) ne fonctionnera pas sur les syst�mes sun4c.
David Miller: il y a un bug dans le fichier d'en-t�te include/linux/tasks.h, cela n�cessite de d�finir NR_CPUS � 64 sur UltraSparc puisqu'il s'agit de la limite sup�rieure pour le mat�riel que nous supportons :-)
(Cort Dougan) Non support�: Syst�mes PPC RS/6000
Rien. Compilation SMP normale (voir plus haut). Comme d'habitude, soyez attentif. Les modules sont sp�cifiques pour UP ou pour SMP. Recompilez les (Paul Mackerras).
Geerten Kuiper : le SMP marche pour la plupart des serveurs AXP, sinon pour tous.
Jay A Estabrook : le SMP semble fonctionner sur la plupart de nos machines [Compaq] avec deux processeurs ou plus. La liste de celles-ci comprend :
En sont exclus :
Aucun (vraiment ? :-) ).
Pour souscrire, envoyez subscribe linux-smp dans le corps du
message �
majordomo@vger.rutgers.edu
Pour se d�sinscrire, envoyez unsubscribe linux-smp dans le corps
du message �
majordomo@vger.rutgers.edu
linux-smp@vger.rutgers.edu
Un grand merci � ceux qui m'ont aid� � maintenir ce HOWTO: