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: