Linux SMP HOWTO David Mentré, David.Mentre@irisa.fr v1.8, 8 novembre 1999 Ce HOWTO passe en revu les principaux problèmes (et j'espère ces solu­ tions)liés la configuration SMP sous Linux. ______________________________________________________________________ Table des matières 1. Introduction 2. Questions indépendantes de l'architecture. 2.1 Coté Noyau 2.2 Coté utilisateur 2.3 Programmation SMP 2.3.1 Méthodes de parallélisation 2.3.2 La librairie C 2.3.3 Languages, Compilateurs et débogueurs 2.3.4 Atres librairies 2.3.5 D'autres points à propos de la programmation SMP 3. Questions spécifiques à l'architecture x86 3.1 Pourquoi cela ne marche-t-il pas avec ma machine ? 3.2 Causes possibles de plantages 3.3 Informations spécifiques aux cartes mère 3.3.1 Cartes mères avec des problèmes connus 3.4 Machine SMP Linux à bas prix (machine double Celeron) 3.4.1 Est-il possible de faire fonctionner une machine double Celeron ? 3.4.2 Comment Linux se comporte-t-il sur les systèmes double Celeron ? 3.4.3 Les processeurs Celeron sont réputés pour être facilement surcadensable. Et les systèmes doubles Celeron ? 3.4.4 Et faire une système quadruple Celeron ? 3.4.5 pourquoi pas mélanger Celeron et Pentium II ? 4. Questions spécifiques concernant l'architecture Sparc 4.1 Quellles sont les machines Sparc supportées ? 4.2 Problèmes spécifique concernant le support SMP Sparc 4.3 Limites SMP spécifiques au noyau courant (2.2) 5. Questions spécifiques concernant l'architecture PowerPC 5.1 Quellles sont les machines PPC supportées ? 5.2 Problèmes spécifiques concernant le support SMP PPC 6. Questions spécifiques concernant l'architecture Alpha 6.1 Quelles sont les machines Alpha supportées ? 6.2 Problèmes spécifique concernant le support SMP Alpha 7. Pointeurs utiles 7.1 Divers 7.2 Programmes et librairies multithread 7.3 Patches spécifiques SMP 7.4 Compilateurs Parallèliseur/Optimiseur pour les machines 586/686 ( 8. Glossary 9. Quoi de neuf ? 10. Liste des contributeurs ______________________________________________________________________ 11.. IInnttrroodduuccttiioonn Linux fonctionne sur les machines SMP (Symmetric Multi-Processors). Le support SMP fut introduit avec la version 2.0 du noyau, et a été largement améliorer depuis. est beaucoup plus fine dans la série 2.2.x que dans la 2.0.x, ce qui permet de meilleures performances quand les processus accèdent au noyau ! HOWTO maintenu par David Mentré (David.Mentre@irisa.fr). La dernière version de ce HOWTO peut être obtenue à · http://www.irisa.fr/prive/mentre/smp-howto/ (France) · http://www.phy.duke.edu/brahma/smp-faq/ (USA) Si vous voulez contribuer à ce HOWTO, je préférerai un diff contre SGML version de ce document, mais toute remarque (en texte pur) sera grandement apprécier. Si vous m'envoyez un e-mail a propos de ce document, s'il vous plaît insérer un tag comme [Linux SMP HOWTO] dans le champ Suject: de votre e-mail. Cela m'aide à trier automatiquement mon courrier (et vous recevrez une réponse plus rapide ;)). Ce HOWTO est une amélioration de first draft écrit par CChhrriiss PPiirriihh. Toutes les informations contenues dans ce HOWTO sont fournies "telle quel". Toutes les garanties, explicites, implicite ou légale, concernant l'exactitude de l'information, de la convenance à quelque usage particulier sont par la présente spécifiquement déclinées. Alors que tous les efforts ont été prit pour assurer l'exactitude des informations contenues dans ce HOWTO, les auteurs n'assument aucune responsabilité pour les erreurs ou omissions, ou dommages résultants de l'utilisation de l'information contenue dans ce document. 22.. QQuueessttiioonnss iinnddééppeennddaanntteess ddee ll''aarrcchhiitteeccttuurree.. 22..11.. CCoottéé NNooyyaauu 1. LLiinnuuxx ssuuppppoorrttee--tt--iill lleess tthhrreeaaddss mmuullttiipplleess ?? SSii jjee llaannccee ddeeuuxx oouu pplluussiieeuurrss pprroocceessssuuss,, sseerroonntt--iillss rreeppaarrttiiss eennttrree lleess ddiifffféérreennttss pprroocceesssseeuurrss ddiissppoonniibblleess ?? Oui. Les processus et les threads du noyau sont repartis entre les processeurs. Ceux de l'espace utilisateur ne le sont pas. 2. QQuueelllleess ssoonntt lleess aarrcchhiitteeccttuurreess SSMMPP ssuuppppoorrttééeess ?? DDee AAllaann CCooxx: 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. RRiicchhaarrdd JJeelliinneekk 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. DDee RRaallff BBääcchhllee: 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 ... 3. CCoommmmeenntt ffaaiitt--oonn uunn nnooyyaauu LLiinnuuxx ssuuppppoorrttaanntt SSMMPP ?? 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. (CC.. PPoolliisshheerr) 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" (MMiicchhaaeell EElliizzaabbeetthh CChhaassttaaiinn). ET autoriser l'horloge temps réel en cochant l'item "RTC support" (de RRoobbeerrtt GG.. BBrroowwnn). 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 RRiicchhaarrdd JJeelliinneekk 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 (JJaakkoobb OOeesstteerrggaaaarrdd). AAllaann CCooxx 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 AAllaann CCooxx). 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 _m_a_k_e _m_r_p_r_o_p_e_r, restaurer votre fichier _._c_o_n_f_i_g, puis recompiler votre noyau (_m_a_k_e _d_e_p, etc.) (WWaaddee HHaammppttoonn). 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 ___________________________________________________________________ 4. CCoommmmeenntt ccoommppiillee--tt--oonn uunn nnooyyaauu LLiinnuuxx nnoonn-SMP ? Dans la série 2.0, ccoommmmeenntteerr 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" (MMiicchhaaeell EElliizzaabbeetthh CChhaassttaaiinn). 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. 5. CCoommmmeenntt ssaavvooiirr ssii ççàà mmaarrcchhee ?? 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 ______________________________________________________________________ 6. QQuueell eesstt llee ssttaattuutt ddee llaa mmiiggrraattiioonn dduu nnooyyaauu vveerrss uunn vveerrrroouuiillllaaggee ffiinn eett llee mmuullttiitthhrreeaaddiinngg ?? 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. (IInnggoo MMoollnnaarr) 7. LLiinnuuxx SSMMPP ssuuppppoorrttee--tt--iill lleess aaffffiinniittééss pprroocceesssseeuurr ?? NNooyyaauuxx ssttaannddaarrdd 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. PPaattcchh 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 utilisa­ teurs à déterminer sur quel processeur ou ensemble de processeurs un processus peut tourner. Les utilisations possibles incluent assignement de thread à des pro­ cesseurs distincts, synchronisation, sécurité (un pro­ cesseur `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: · Assignation d'un processus/thread à processeur spécifique · Interdire un processeur d'exécuter certains processus · Empêcher strictement l'utilisation d'un processeur · Assigner à un processeur un _unique_ processus (et ces fils) · Information sur l'état du processeur · création/destruction d'ensemble de processeurs, sur lesquels les processus peuvent être limités 8. OOùù ddooiiss--jjee rraappppoorrtteerr lleess bboogguueess SSMMPP ?? S'il vous plaît rapportez les bogues à linux-smp@vger.rutgers.edu. 9. AA pprrooppooss ddeess ppeerrffoorrmmaanncceess SSMMPP ?? 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. 22..22.. CCoottéé uuttiilliissaatteeuurr 1. AAii--jjee vvrraaiimmeenntt bbeessooiinn ddee SSMMPP ?? 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.(CC.. PPoolliisshheerr) 2. EEsstt--ccee qquuee jj''oobbttiieennss lleess mmêêmmeess ppeerrffoorrmmaanncceess dd''uunn bbiipprroocceesssseeuurr 330000 MMHHzz qquu''uunn pprroocceesssseeuurr 660000 MMHHzz ?? 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. (WWaaddee HHaammppttoonn). :) 3. CCoommmmeenntt ppeeuutt--oonn aaffffiicchheerr lleess ppeerrffoorrmmaanncceess ddee pplluussiieeuurrss pprroocceesssseeuurrss ?? Merci à SSaammuueell SS.. CChheessssmmaann, ici se trouvent quelques utilitaires pratiques: CChhaarraacctteerr bbaasseedd:: 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, GGrreeggoorryy RR.. WWaarrnneess a rendu disponible un patch à http://queenbee.fhcrc.org/~warnes/procps GGrraapphhiiqquuee:: 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 KKuummssuupp LLeeee 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. (HH.. PPeetteerr AAnnvviinn) 4. CCoommmmeenntt aauuttoorriisseerr pplluuss dd''uunn pprroocceessssuuss lloorrss ddee llaa ccoommppiillaattiioonn dduu nnooyyaauu ?? 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 RRaallff BBääcchhllee). 5. PPoouurrqquuooii llee tteemmppss ddoonnnneerr ppaarr llaa ccoommmmaannddee time est erroné ? (de JJooeell MMaarrcchhaanndd) 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" (JJaakkoobb ØØsstteerrggaaaarrdd). Ce bogue est corrigé dans les 2.2. 22..33.. PPrrooggrraammmmaattiioonn SSMMPP Section par JJaakkoobb ØØsstteerrggaaaarrdd. 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. 22..33..11.. MMéétthhooddeess ddee ppaarraalllléélliissaattiioonn 1. threads POSIX (POSIX Threads) 2. PVM / MPI Message Passing Libraries 3. fork() -- Processus multiples 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. 22..33..22.. LLaa lliibbrraaiirriiee CC Les vieilles librairies ne sont pas sures au niveau threads. Il est très important que vous utilisiez la GNU LibC (gglliibbcc), aussi connue sous le nom de lliibbcc66. 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. 22..33..33.. LLaanngguuaaggeess,, CCoommppiillaatteeuurrss eett ddéébboogguueeuurrss 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 (gglliibbcc). Il y a néanmoins quelques problèmes: 1. Quand vous compilez en C ou C++, utilisez --DD__RREEEENNTTRRAANNTT définit dans la ligne de commande du compilateur. Il est nécessaire de faire fonctionner certaines fonctions error-handling comme la variable errno. 2. Quand vous utilisez C++, si deux threads rencontrent des exceptions simultanément, le programme retournera une erreur de segmentation. Le compilateur ne génère pas de code d'exception adapté aux threads. Une manière de contourner le problème est de mettre un pthread_mutex_lock(&global_exception_lock) dans le(s) constructeurs de chaques classes que vous throw(), et mettre le pthread_mutex_unlock(...) correspondant dans le destructeur. Ce n'est pas beau mais çà marche. La solution est donnée par MMaarrkkuuss FFeerrcchh. Le GNU Débogueur GGDDBB à 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 gglliibbcc 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 gglliibbcc. 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 AAssttuuccee:: 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 ttoopp pour obtenir le PID du processus. Lancez GDB tel que ggddbb pprrooggrraamm ppiidd. 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 bbtt ou d'autre pour voir ce qui arrive. 22..33..44.. AAttrreess lliibbrraaiirriieess EElleeccttrriiccFFeennccee:: 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. 22..33..55.. DD''aauuttrreess ppooiinnttss àà pprrooppooss ddee llaa pprrooggrraammmmaattiioonn SSMMPP 1. OOùù ppuuiiss--jjee ttrroouuvveerr pplluuss dd''iinnffoorrmmaattiioonn ssuurr llaa pprrooggrraammmmaattiioonn ppaarraallllèèllee ?? Voyez Linux Parallel Processing HOWTO Beaucoup d'informations utiles peuvent être trouvé à Parallel Processing using Linux Voyez aussi Linux Threads FAQ 2. EExxiissttee--tt--iill ddeess pprrooggrraammmmeess oouu ddeess lliibbrraaiirriieess uuttiilliissaanntt lleess tthhrreeaaddss ?? 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: OOppeennGGLL MMeessaa lliibbrraarryy Merci à DDaavviidd BBuuccccaarreellllii, aannddrreeaass SScchhiifffflleerr et EEmmiill BBrriiggggss, 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 BBLLAASS 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. TThhee GGIIMMPP EEmmiill BBrriiggggss, 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. 33.. QQuueessttiioonnss ssppéécciiffiiqquueess àà ll''aarrcchhiitteeccttuurree xx8866 33..11.. PPoouurrqquuooii cceellaa nnee mmaarrcchhee--tt--iill ppaass aavveecc mmaa mmaacchhiinnee ?? 1. PPuuiiss--jjee uuttiilliisseerr llee mmooddee SSMMPP aavveecc uunn CCPPUU CCyyrriixx//AAMMDD//nnoonn--IInntteell ?? RRééppoonnssee ccoouurrttee:: non. RRééppoonnssee lloonngguuee 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) FYI -Cyrix et AMD support le standard non-propriétaire OpenPIC SMP mais actuellement il n'y a pas de carte mère l'utilisant. 2. PPoouurrqquuooii mmoonn vviieeuuxx CCoommppaaqq nnee mmaarrcchhee ppaass ?? 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 cocher "full Table mode". C'est une recommandation officielle de Compaq, bien que j'aie été incapable de trouver cette option dans le BIOS... (DDaanniieell RRooeesseenn) 3. PPoouurrqquuooii mmoonn AALLRR nnee ffoonnccttiioonnnnee--tt--iill ppaass ?? De RRoobbeerrtt HHyyaatttt: ALR Revolution quad-6 semble à peu près sure, alors que quelques machines revolution quad plus vieilles sans processeurs P6 ne semble pas "fiables"... 4. PPoouurrqquuooii mmaa mmaacchhiinnee SSMMPP eesstt ssii lleennttee ?? ou PPoouurrqquuooii uunn pprroocceesssseeuurr mmoonnttrree uunnee vvaalleeuurr bbooggoommiippss bbaassssee aalloorrss qquuee llee pprreemmiieerr eesstt nnoorrmmaall ?? De AAllaann CCooxx: Si un de vos processeurs rapporte une valeur bogomips très basse c'est que son cache n'est pas activé. Votre vendeur vous à probablement fournis un BIOS bogué. Obtenez un patch pour contourner cela ou mieux retourné la à votre vendeur et acheté 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. 5. JJ''aaii eenntteenndduu ddiirree qquuee ddeess mmaacchhiinneess IIBBMM aavvaaiieenntt ddeess pprroobbllèèmmeess 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. 6. IIll yy aa--tt--iill uunn qquueellccoonnqquuee aavvaannttaaggee ddeess ssppéécciiffiiccaattiioonn MMPP 11..44 ssuurr lleess 11..11 ?? Non (selon Alan :) ), 1.4 est juste une spécification plus stricte de 1.1. 7. ppoouurrqquuooii ll''hhoorrllooggee ddéérriivvee ssii rraappiiddeemmeenntt qquuaanndd jjee ffoonnccttiioonnnnee eenn mmooddee SSMMPP ?? Ceci est un problème connu avec la gestion des IRQ et les longs blocages noyau dans la série 2.0 des noyaux. Pensez à mettre à jour votre système vers un 2.2 plus récent. De JJaakkoobb OOeesstteerrggaaaarrdd: Ou, pensez à utiliser xntpd. Cela devrait garder votre horloge à l'heure. (je pense avoir entendu qu'activer RTC dans le noyau corrige aussi le problème de dérive de l'horloge. Cela à marché pour moi ! Mais je ne suis pas sure si cela est général ou si j'ai juste été chanceux) Il y a quelques corrections du noyau dans les derniers 2.2.2 qui devraient résoudre ce problème. 8. PPoouurr qquuooii mmeess pprroocceesssseeuurrss ssoonntt--iillss nnuumméérroottééss 00 eett 22 aauu lliieeuu ddee 00 eett 11 ((oouu aauuttrree nnuumméérroottaattiioonn bbiizzaarrrree)) ?? Le numéro du processeur est fixé par le fabricant de la carte mère et ne veux absolument rien dire. Ignorez le. 9. MMoonn ssyyssttèèmmee qquuaaddrruuppllee XXeeoonn ppllaannttee ddèèss qquu''iill aa ddééccoommpprreesssséé llee nnooyyaauu (DDoouugg LLeeddffoorrdd) Essayez de recompiler LILO avec le support LARGE_EBDA et faite attention à bien toujours utiliser bzImage quand vous compiler le noyau. Cela semble avoir résolu le problème de plantage au démarrage ici sur une carte mère Intel multi-Xeon. Néanmoins, s'il vous plaît notez que cela semble aussi affecter LILO en cela que l'option root= ne fonctionne plus, faite donc bien attention d'avoir appliqué 'rdev' à votre noyau en moment où vous lancez LILO afin d'être sur que votre noyau charge correctement le système de fichier racine au démarrage. (RRoobbeerrtt MM.. HHyyaatttt) Avec 3 processeurs, avez-vous un terminateur dans le 4ème emplacement ? 10. DDuurraanntt llee ddéémmaarrrraaggee llaa mmaacchhiinnee ppllaannttee eenn ssiiggnnaallaanntt uunn pprroobbllèèmmee IIOOAAPPIICC Essaye l'option de démarrage "noapic" (JJoohhnn AAllddrriicchh) et/ou "reboot=bios" (TTeerrrryy SShhuullll). 11. MMoonn ssyyssttèèmmee ssee bbllooqquuee lloorrss ddee ttrraaffiicc NNFFSS iinntteennssee Essaye le dernier noyau 2.2.x et le patch knfsd. Cela est en cour d'investigation. (WWaaddee HHaammppttoonn) 12. MMoonn ssyyssttèèmmee bbllooqquuee ssaannss mmeessssaaggee ooooppss 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 nombreuse correction SMP. Plusieurs personnes ont rapporté ces noyaux comme instable pour le SMP. Ces mêmes noyaux peuvent avoir des problèmes NFS qui peuvent provoquer des blocages. Aussi, utiliser une console série pour capturer vos messages oops. (WWaaddee HHaammppttoonn) Si le problème persiste (et les autres suggestions sur cette listes n'ont pas aidé non plus), alors vous devriez essayer les derniers noyaux 2.3. Ils ont un code SMP/APIC plus bavard (et plus robustes), et un code de prévention contre les blocage dur qui produit des oops plus significatifs au lieu de planter silencieusement. (IInnggoo MMoollnnaarr) 13. DDéébboogggguueerr ddeess bbllooccaaggeess (item par WWaaddee HHaammppttoonn) Un bon moyen de déboguer les blocages est de 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, mais n'utiliser 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 est fonctionnel, après avoir démarrer avec votre nouveau noyau, /cat /proc/interrupts et vérifiez que vous obtenez des NMI. Quand la machine bloque, vous devriez obtenir un oops. Vous pouvez aussi essayer l'option %eip. Cela autorise le noyau à écrire sur la console l'adresse %eip chaque fois qu'une fonction du noyau est appelée. Quand la machine bloque, écrivez sur un papier la première colonne ordonnée selon la seconde colonne et ensuite cherchez les adresses dans le fichier System.map. Cela ne marche qu'en mode console. Notez aussi que l'utilisation de console série facilite grandement le débogage des blocages noyau, pas seulement les blocages des noyaux SMP ! 14. MMeessssaaggeess ""AAPPIICC eerrrroorr iinntteerrrruupptt oonn CCPPUU##nn,, sshhoouulldd nneevveerr hhaappppeenn"" ddaannss lleess llooggss Un message comme: ___________________________________________________________________ APIC error interrupt on CPU#0, should never happen. ... APIC ESR0: 00000002 ... APIC ESR1: 00000000 ___________________________________________________________________ indique la 'réception d'une erreur cheksum'. Cela ne peut être provoqué par Linux car la partie checksum des messages APIC est complètement matérielle. Cela peut être un matériel marginal. Tant que vous ne percevez pas d'instabilité, ils ne sont pas problématiques - les messages APIC sont renvoyés jusqu'à ce qu'il soient délivrés. (IInnggoo MMoollnnaarr) 33..22.. CCaauusseess ppoossssiibblleess ddee ppllaannttaaggeess Dans cette section vous trouverez quelques information sur les causes ppoossssiibbllee de plantage sur une machine SMP (crédits duent à JJaakkoobb ØØsstteerrggaaaarrdd pour cette partie). Autant que je sache (David), ces problèmes sont spécifiques aux plateformes Intel. · PPrroobbllèèmmeess ddee rreeffrrooiiddiisssseemmeenntt De RRaallff BBääcchhllee: [Concernant la taille des boîtiers et les ventilateurs] Il est important que l'air circule. 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 coté, j'ai vu des boîtiers surdimensionnés provoquer de gros problèmes. Il y a des boîtiers au format tour sur le marcher qui sont actuellement pire à rafraîchir que boîtier 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 aussi utiles. Bien sur vous pouvez toujours aller à Radio Shack (ou similaire) et acheter un ventilateur. Vous pouvez utiliser lm_sensor pour surveiller la température des plus récent processeurs PII et PIII. Cela peut vous aider à déterminer si la chaleur est un problème ou non. (WWaaddee HHaammppttoonn) · MMaauuvvaaiissee bbaarrrreettttee ddee mméémmooiirree N'achetez pas de la RAM bon marché et ne mélanger pas des barrettes différente sur une même carte mère, c'est difficile à cause de cela. Tout spécialement les cartes mères Tyan qui sont connues pour être difficile sur la vitesse de la RAM (voir le paragraphe ci-dessous sur Tyan pour une solution possible). 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. (WWaaddee HHaammppttoonn) · MMaauuvvaaiissee ccoommbbiinnaaiissoonn ddee pprroocceesssseeuurrss ddee ccaaddeennccee ddiifffféérreennttee Vérifier /proc/cpuinfo pour voir si vos processeurs sont à la même cadence. · SSii vvoottrree ssyyssttèèmmee eesstt iinnssttaabbllee,, aalloorrss NNEE PPAASS ll''oovveerrcclloocckkeerr !! ... et même si il est stable, NE PAS l'overclocker. De RRaallff BBääcchhllee: le surcadencement (overclocking) pose des problèmes très subtiles. J'ai un bel exemple, une de mes vieilles machines surcadencées fait des erreurs de calcul pour quelques pixels d'une fractale de 640 X 400. Le problème est seulement visible quand vous les comparées en utilisant des outils. Le mieux est donc de ne _j_a_m_a_i_s_, _n_e_v_e_r_, _n_u_n_c_a_s_, _n_i_e_m_a_l_s surcadencer. · NNooyyaauuxx 22..00..xx eett éétthheerrnneett rraappiiddee (de RRoobbeerrtt GG.. BBrroowwnn) Les noyaux 2.0.x sur des systèmes éthernet rapide et hautes performance ont des problèmes significatifs (et connus) avec les conditions de course/interblocage (race/deadlock) dans la prise en charge des interruptions réseau. La solution est d'obtenir la dernière version des pilotes 100BT en développement à CESDIS Linux Ethernet device drivers site (ceux qui sont définent SMPCHECK). · UUnn bboogguuee ddaannss llee cchhiippsseett 444400FFXX (de EEmmiill BBrriiggggss) Si vous avez un système utilisant le chipset 440FX alors votre problème avec les blocages est peut-être due à une erreur documentée du chipset. Voici la référence. Références: Intel 440FX PCIset 82441FX (PMC) et 82442FX (DBX) Specification Update. pg. 13 http://www.intel.com/design/pcisets/specupdt/297654.htm Le problèmes peut être résolut avec un contournement par le BIOS (ou un patch du noyau) et en fait David Wragg a écrit un patch qui est inclus dans le patch MTRR de Richard Gooch's. Pour plus d'information et une solution voyez ici: http://nemo.physics.ncsu.edu/~briggs/vfix.html · NNEE PPAASS llaanncceerr eemmmm338866..eexxee aavvaanntt ddee ddéémmaarrrreerr LLiinnuuxx SSMMPP De MMaarrkk DDuugguuiidd, Règle implicite #1 avec une carte mère W6LI. ;) · SSii llaa mmaacchhiinnee rreeddéémmaarrrree//ggèèllee aauu bboouutt dd''uunn mmoommeenntt,, iill ppeeuutt iill yy aavvooiirr ddeeuuxx bboonnnnee rraaiissoonnss lliiééeess àà llaa mméémmooiirree eett aauu BBIIOOSS (de JJaakkoobb ØØsstteerrggaaaarrdd) · Si le BIOS possède des réglages comme "memory hole at 16M" et/ou "OS/2 memory > 64MB", essayez de les désactiver tous les deux. Linux ne réagit pas toujours très bien avec ces deux options. · Si vous avez plus de 64 MB de mémoire dans votre machine, et que vous spécifié manuellement le chiffre exacte dans la configuration de LILO, vous devriez spécifier 1 MB de moins que ce vous avez réellement dans votre machine. Si vous avez 128 MB, votre ligne dans votre lilo.conf ressemble à: append="mem=127M" · SSooyyeezz aavveerrttiiss ddeess pprroobbllèèmmeess ccoonncceerrnnaanntt lleess IIRRQQ Parfois, certaines cartes ne sont pas reconnus ou peuvent déclencher des conflits d'IRQ. Essayez de mettre les cartes sur des slots différents et si possible les assigner à des IRQ différentes. Contribué par hhAASSCCIIII : 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 BIOS setup comme "MP 1.4 mode" ou "route PCI interrupts through IOAPIC", ou "OS Type" non configurer ni pour DOS ni pour Novell (IInnggoo MMoollnnaarr). · AAccccèèss aauuxx ddiissqquueetttteess ppeennddaanntt qquuee llee ssoonn eesstt aaccttiiff Si vous bloquez alors que vous essayez d'accéder au lecteur de disquette (par exemple pendant que du son est joué) vous devriez peut-être éditer le fichier drivers/pci/quirks.c et configurer /int isa_dma_bridge_buggy = 1; C'est un problème avec mon Dell WS400 dual PII/300, 2.2.x, SMP (WWaaddee HHaammppttoonn). 33..33.. IInnffoorrmmaattiioonnss ssppéécciiffiiqquueess aauuxx ccaarrtteess mmèèrree _S_'_i_l _v_o_u_s _p_l_a_i_t _n_o_t_e_z: Des informations plus spécifique peuvent être trouvées avec la liste des Cartes mère supposées fonctionnées sous Linux SMP 33..33..11.. CCaarrtteess mmèèrreess aavveecc ddeess pprroobbllèèmmeess ccoonnnnuuss · Aucune pour l'instant 33..44.. MMaacchhiinnee SSMMPP LLiinnuuxx àà bbaass pprriixx ((mmaacchhiinnee ddoouubbllee CCeelleerroonn)) (SSttéépphhaannee ÉÉccoolliivveett) Les machines SMP Linux les moins chère avec des processeurs achetable de nos jours sont les systèmes double Celeron. Un tel système n'est pas officiellement possible selon Intel. Il vaut mieux penser à la seconde génération de Celeron, ceux avec 128 Kb de cache L2. 33..44..11.. EEsstt--iill ppoossssiibbllee ddee ffaaiirree ffoonnccttiioonnnneerr uunnee mmaacchhiinnee ddoouubbllee CCeelleerroonn ?? RRééppoonnssee ooffffiicciieellllee dd''IInntteell:: non, le Celeron ne peut pas fonctionner en mode SMP. RRééppoonnssee pprraattiiqquuee:: c'est possible, mais cela demande une altération matérielle pour les processeurs Slot 1. La manipulation est décrite par Tomohiro Kawada sur sa page Dual Celeron System . Naturellement, ce genre de modification annule 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 ou peut même être vendu pré-cablé pour une utilisation SMP. (AAnnddyy PPoolliinngg, HHaannss -- EErriikk SSkkyyttttbbeerrgg, JJaammeess BBeeaarrdd) Il y a aussi une carte mère (ABIT BP6) autorisant deux Celerons dans le format Socket 370 à être inséré (MMaarrttiijjnn KKrruuiitthhooff, RRyyaann MMccCCuuee). ABIT Computer BP6 verifiée, testée et native sous linux avec deux ppga socket 370 (AAnnddrree HHeeddrriicckk). 33..44..22.. CCoommmmeenntt LLiinnuuxx ssee ccoommppoorrttee--tt--iill ssuurr lleess ssyyssttèèmmeess ddoouubbllee CCeelleerroonn ?? Bien, merci. 33..44..33.. EEtt lleess ssyyssttèèmmeess ddoouubblleess CCeelleerroonn ?? LLeess pprroocceesssseeuurrss CCeelleerroonn ssoonntt rrééppuuttééss ppoouurr êêttrree ffaacciilleemmeenntt ssuurrccaaddeennssaabbllee.. Cela ppeeuutt marcher. Néanmoins, surcadencer un tel système n'est pas aussi facile à faire que pour un monoprocesseur. Ce n'est définitivement pas une bonne idée pour un système de production. Pour une utilisation personnelle, des systèmes doubles Celeron 300 A fonctionnant parfaitement à 450 MHz ont été signalés. (ddee nnoommbbrreeuusseess ppeerrssoonnnneess) 33..44..44.. EEtt ffaaiirree uunnee ssyyssttèèmmee qquuaaddrruuppllee CCeelleerroonn ?? 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 (?). 33..44..55.. ppoouurrqquuooii ppaass mmééllaannggeerr CCeelleerroonn eett PPeennttiiuumm IIII ?? Un système utilisant un Celeron "ré-autorisé" et un pentium II à la même cadence ppeeuutt tthhééoorriiqquueemmeenntt fonctionner. AAlleexxaannddrree CChhaarrbbeeyy à fabriqué un tel système: · Carte mère Asus P2B-D, proc 1: Celeron 366, proc 2: Pentium II 400@266 · Les fréquences de bus 66Mhz et 75Mhz furent fonctionnelles · Le processeur le plus rapide (dans ce cas le Celeron) doit être placé sur le deuxième slot. Inverser les processeurs (le plus rapide le premier) conduit rapidement à un échec. 44.. QQuueessttiioonnss ssppéécciiffiiqquueess ccoonncceerrnnaanntt ll''aarrcchhiitteeccttuurree SSppaarrcc 44..11.. QQuueelllllleess ssoonntt lleess mmaacchhiinneess SSppaarrcc ssuuppppoorrttééeess ?? Citation de la page web UltraLinux (systèmes SMP seulement): · Workstation UltraSPARC à base de PCI: Ultra60, Ultra450 · Serveurs UltraSPARC à base de SBUS: Enterprise 1, 2, 150 · Serveurs large UltraSPARC à base de SBUS: Enterprise 3000, 4000, 5000, 6000, 10000 · Serveurs UltraSPARC à base de PCI : Enterprise 250, 450 · Machines SPARC sun4m SMP (AAnnttoonn BBllaanncchhaarrdd) UltraLinux a fonctionné sur une machine de 14 processeurs (voir la sortie dmesg ). 44..22.. PPrroobbllèèmmeess ssppéécciiffiiqquuee ccoonncceerrnnaanntt llee ssuuppppoorrtt SSMMPP SSppaarrcc (DDaavviidd MMiilllleerr) Il ne devrait pas il y avoir d'inquiétudes. Le seul problème connu, et que nous n'avons pas l'intention de corriger, est que si compilé un noyau SMP pour des systèmes 32bits (ie. non-ultrasparc), ce noyau ne fonctionnera pas sur les systèmes sun4c. 44..33.. LLiimmiitteess SSMMPP ssppéécciiffiiqquueess aauu nnooyyaauu ccoouurraanntt ((22..22)) (DDaavviidd MMiilllleerr) 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 comme c'est la plus haute limite pour le matériel que nous supportons :-) 55.. QQuueessttiioonnss ssppéécciiffiiqquueess ccoonncceerrnnaanntt ll''aarrcchhiitteeccttuurree PPoowweerrPPCC 55..11.. QQuueelllllleess ssoonntt lleess mmaacchhiinneess PPPPCC ssuuppppoorrttééeess ?? · Cartes mères PowerSurge (incluant UMAX s900) · PowerMac · Motorola MTX: support en cour de développement. Les patches ne sont pas encore inclus dans le noyau principale (TTrrooyy BBeennjjeeggeerrddeess) (CCoorrtt DDoouuggaann) Non supporté: Systèmes PPC RS/6000 55..22.. PPrroobbllèèmmeess ssppéécciiffiiqquueess ccoonncceerrnnaanntt llee ssuuppppoorrtt SSMMPP PPPPCC Rien. Compilation SMP normale (voir plus haut). Comme d'habitude, soyez attentif, Les modules sont spécifiques pour UP ou pour SMP. Recompiler les. (PPaauull MMaacckkeerrrraass) 66.. QQuueessttiioonnss ssppéécciiffiiqquueess ccoonncceerrnnaanntt ll''aarrcchhiitteeccttuurree AAllpphhaa 66..11.. QQuueelllleess ssoonntt lleess mmaacchhiinneess AAllpphhaa ssuuppppoorrttééeess ?? (GGeeeerrtteenn KKuuiippeerr) Le SMP marche pour la plupart, sinon tous, les serveurs AXP. (JJaayy AA EEssttaabbrrooookk) Le SMP semble fonctionner sur la plupart de nos machines [Compaq] avec deux processeurs ou plus. Ceux-ci comprend: · AS2000/2100 (SABLE) · AS4000/4100 (RAWHIDE) · DS20 (DP264) Cela n'inclus pas : · AS2100A (LYNX) · TurboLaser bigboys (8200/8400) 66..22.. PPrroobbllèèmmeess ssppéécciiffiiqquuee ccoonncceerrnnaanntt llee ssuuppppoorrtt SSMMPP AAllpphhaa Aucun (vraiment ? :-) 77.. PPooiinntteeuurrss uuttiilleess 77..11.. DDiivveerrss · Parallel Processing en utilisant Linux · Linux Parallel Processing HOWTO · ((ddééppaasssséé)) Page d'acceuille SMP Linux · linux-smp mailing list Pour ssoouussccrriirree, envoyer subscribe linux-smp dans le corps du message à majordomo@vger.rutgers.edu Pour se ddééssiinnssccrriirree, envoyer unsubscribe linux-smp dans le corps du message à majordomo@vger.rutgers.edu Archives Linux SMP Archives Linux SMP à progressive-comp.com · La librairie pthread de Xavier Leroy · Les Cartes mères qui paraît-il marche avec Linux SMP · procps · patch pour procps pour 2.2.x · xosview · xosview pour 2.2.x · Performance SMP de Linux · CESDIS Linux Ethernet device drivers site · Systèmes Double Celeron 77..22.. PPrrooggrraammmmeess eett lliibbrraaiirriieess mmuullttiitthhrreeaadd · Linux Threads FAQ · Programmes multithread sur linux · BLAS et FFTs optimizé Pentium pro pour Intel Linux (pas diponible tout de suite, mais une librairie double processeurs est prévue pour le 5/27/98, voir Blas News pour plus de détails) · Librairie Mesa (aves multithread expérimental) · Plugins parallèles pour The GIMP 77..33.. PPaattcchheess ssppéécciiffiiqquueess SSMMPP · Patches noyau de Forissier · Patch pour un bug dans le chipset 440FX · Patch MTRR (dernière version: 1.9) · PSET - Processor Sets for the Linux kernel · Patches SMP de Ingo Molnar (pour les experts seulement, s'il vous plait lisez linux- smp@vger.rutgers.edu) 77..44.. CCoommppiillaatteeuurrss PPaarraallllèèlliisseeuurr//OOppttiimmiisseeuurr ppoouurr lleess mmaacchhiinneess 558866//668866 (( SSuummiitt RRooyy )) · Pentium Compiler Group créateur de pgcc · Absoft , compilateur Fortran 90 et Fortran 77 · The Portland Group, Inc. , supporte le standard OpenMP pour la parallèlisation Fortran sur Linux · Pacific-Sierra Research Corporation , possède un compilateur gratuit F90 pour Linux, et aussi des compilateur parallèlisant pour SMP Linux · Applied Parallel Research , actuellement possède des compilateurs parallèliseur pour WinNT · KAI possède un compilateur C++ pour Linux qui comprend OpenMPI. Cela s'appelle Guide_OpenMP. Information à http://www.kai.com/parallel/kappro/guide. (GGeerroo WWeeddeemmaannnn) 88.. GGlloossssaarryy · SSMMPP Multi-Processeur Symmétrique · AAPPIICC Controleur d'Interruption Programmable Avancé · tthhrreeaadd Un thread est l'activiter processeur dans un processus. Un même processus peut avoir de multiples thread. Ces threads partagent l'espace adresse du processus et peuvent donc par-là partager des données. · pptthhrreeaadd Posix thread, threads définie par le standard Posix. · AAPPMM Gestion avancée de l'énergie 99.. QQuuooii ddee nneeuuff ?? vv11..88,, 88 nnoovveemmbbrree 11999999 · La carte mère quadruple celeron était un canular, restoration de l'ancien paragraphe (SSiimmeenn TTiimmiiaann TThhoorreesseenn) vv11..77,, 66 nnoovveemmbbrree 11999999 · Nouvelle introduction (CC.. PPoolliisshheerr aka cp) · De nombreuses corrections typographiques et grammaticales (cp) · Paragraphe d'introduction sur la compliation du noyau (cp) · Paragraphe d'introduction sur les besions SMP (cp) · Référence sur KAI un compilateur optimisé (GGeerroo WWeeddeemmaannnn) · Les cartes mères quadruple celeron existent (JJeeffffrreeyy HH.. IInnggbbeerr) vv11..66,, 2211 ooccttoobbrree 11999999 · Ajout d'information sur la perturbation horaire de xosview · Ajout du message d'information "Erreur d'interruption APIC sur le CPU#n" · Ajout d'information sur les blocages matériels · Suppression de la section "Comment obtenir un maximum de performance" (obsolète) · Ajout d'information sur les sytèmes double processeurs avec différents processeurs x86 (un Celeron et un P-II) vv11..55,, 44 ooccttoobbrree 11999999 · Plus de précision das la description de PSET vv11..44,, 3300 sseepptteemmbbrree 11999999 · Précision sur l'activation du support MTRR pour les noyaux SMP x86 (moi) vv11..33,, 2299 sseepptteemmbbrree 11999999 · Beaucoup beaucoup de corrections grammaticales et typographique (WWaaddee HHaammppttoonn aka hww) · Ajout d'information dans la courte introduction à propos des différences entre 2.2/2.4/2.0 (hww) · Ajout des choses à faire pas à pas pour recompiler le noyau (hww et moi) · Ajout d'information concernant les problèmes liés aux modules SMP/UP (hww) · Ajout de précision dans la section Threads Posix concernant les threads utilisateurs vs. les threads du noyau (hww) · Nouvel item à propos de NFS et des blocages du noyau (hww) · Nouvel item à propos des blocage noyau sans message d'alerte (hww) · Nouvel item à propos du débogage des problèmes de blocage (hww) · Ajout d'information à propos des problèmes de dégagement de chaleur (hww) · Divers mise à jour que j'ai oublié (hww) · Nouvel item à propos des accès disquette et du son (hww) vv11..22,, 2277 sseepptteemmbbrree 11999999 · Changement de nom: ce document est maintenant un howto. TWD, et rapide! (GGuuyyllhheemm AAzznnaarr) vv11..11,, 2266 sseepptteemmbbrree 11999999 · Ajout d'un lien vers le premier brouillon de la FAQ de Chris Pirish · Extension des problèmes liés aux IRQ vv11..0000,, 2255 sseepptteemmbbrree 11999999 · Première mise à jour depuis bien longtemps ! · Retraitement de toute la FAQ: le 2.2 est là et le 2.4 arrive · Ajout des informations sur le verrouillage noyau de Ingo Molnar · Suppression de l'item "Quelle seront les performance de mes applications sous SMP": dépassé · Suppression de l'item "Mon système SMP se verrouille tout le temps.": dépassé · Suppression de l'item "Vous utilisez le 2.0.35, n'est-ce pas ?": dépassé · Suppression de l'item "Certains matériels sont aussi connu pour posé des problèmes.": dépassé · Effacement de la section "Cartes mère avec des problèmes connus". Nous devrions recommencer du début. · Suppression de la section "Carte mère sans problèmes connus": dépassée · Mise à jour de la section celeron (de nombreuses personnes) · Ajout de "Les machines SPARC sun4m SMP" dans les machines Sparc supportées (AAnnttoonn BBllaanncchhaarrdd) · Ajout de l'item "Durant le démarrage la machine se bloque en signalant un problème IOAPIC" dans la section "Pourquoi cela ne marche-t-il pas sur ma machine ?" · Ajout de l'item "A propos des performances SMP ?" · Mise à jour de l'item "Pourquoi mon vieux Compaq ne marche-t-il pas ?" · Réparation d'un lien dépassé · Ajout d'un pointeur vers les patches de test SMP d'Ingo vv00..5544,, 1133 mmaarrss 11999999 · Ajout de la section à propos des systèmes SMP Alpha vv00..5533,, 0088 mmaarrss 11999999 · Ajout de la section sur les systèmes PowerPC SMP vv00..5522,, 0077 mmaarrss 11999999 · Ajout de la section sur les systèmes Sparc SMP vv00..5511,, 0066 mmaarrss 11999999 · Ajout de la section dual-celeron · Suppression de la section Adaptec · Mise à jour du lien procps · Mise à jour du lien xosview · Ajout d'une réponse pour le plantage du quadri Xeon · Mise à jour de l'item à propos du patch de la glibc pour gd: devrait être inclus dans la RH 5.2 vv00..5500,, 0033 fféévvrriieerr 11999999 · Mise à jour du lien "Programmes Multithread sous linux" vv00..4499,, 1133 jjaannvviieerr 11999999 · Mise à jour à propos de CONFIG_SMP. Ajout du .txt dans Documentation/smp. (MMiicchhaaeell EElliizzaabbeetthh CChhaassttaaiinn) vv00..4488,, 1100 ddéécceemmbbrree 11999988 · Fautes d'orthographes corrigée. Adresses email corrigée. vv00..4477,, 2200 nnoovveemmbbrree 11999988 · Ajout de la mention du patch MTRR est inclus 2.0.36 (lié à des problème de BogoMips) vv00..4466,, 1100 nnoovveemmbbrree 11999988 · Mise à jour à propos des cartes mère Epox KP6-LS vv00..4455,, 2255 ooccttoobbrree 11999988 · Correction d'une erreur concernant le fichier /proc/stat · Ajout d'un pointeur vers le site CESDIS Ethernet Linux Drivers vv00..4444,, 1144 ooccttoobbrree 11999988 · Mise à jour du lien vers la page web: _C_a_r_t_e_s _m_è_r_e _s_u_p_p_o_s_é_e_s _f_o_n_c_t_i_o_n_n_é_s _s_o_u_s _L_i_n_u_x _S_M_P · Ajout de l'explication de Jakob: comment chronométrer un système SMP avec les noyaux 2.0 vv00..4433,, 99 sseepptteemmbbrree 11999988 · Mise à jour de la première question dans la section 3.1 · Mise à jour du lien mt-Mesa: multi-thread est maintenant inclus comme expérimental dans la distribution Mesa vv00..4422,, 22 sseepptteemmbbrree 11999988 · Mise à jour cosmétique dans la section 3.3 · Deux liens sont marquer comme obsolètes (multithreaded Mesa et performance SMP) · Mise à jour de l'item à propos des threads et des exceptions en C++ (sect 3.3) vv00..4411,, 11 sseepptteemmbbrree 11999988 · Ajout d'une section majeur: "3.3 Programmation SMP" écrite par Jakob Østergaard · Déplacement de la section "3.2 Coté utilisateur" vers la section 3.3 vv00..4400,, 2277 aaooûûtt 11999988 · Mise à jour: section 3.1, item 7: processor affinity vv00..3399,, 2277 aaooûûtt 11999988 · Mise à jour nécessaire du BOIS Award pour les cartes mères Tyan (hhAASSCCIIII) · Ajout d'un item sur les IRQ dans la section plantage (moi et hhAASSCCIIII) · Ajout du bon support de l'Asus P2B-DS (UUllff RRoommppee) · Ajout d'une autre archive smp-list dans la section pointeur (HHaannkk LLeeiinniinnggeerr) vv00..3388,, 88 aaooûûtt 11999988 · Ajout d'un pointeur vers la FAQ Linux Threads vv00..3377,, 3300 JJuuiilllleett 11999988 · EEmmiill BBrriiggggss est en train de travailler sur des plugins parallèles pour Gimp (voir "Il y existe-t-il des programmes ou des library utilisant les threads ?", section "Coté utilisateur") vv00..3366,, 2266 JJuuiilllleett 11999988 · Merci à JJaakkoobb ØØsstteerrggaaaarrdd, deux changement dans "Possible causes of Crash" · Changé le 2.0.33 pour le 2.0.35 (dernier noyau stable) · Ajout de la section "Les plantages liés au BIOS" vv00..3355,, 1144 JJuuiilllleett 11999988 · Ajout des N440BX Server Board dans carte-mère-sans-aucun- problème · Ajout d'une succes story pour la carte mère GigaByte avec une mise à jour du BIOS · Ajout de la section "Comment obtenir les performances maximum ?" (attend vos suggestions ;) vv00..3344,, 1100 jjuuiinn 11999988 · Ajout de la section "Parallelizing/Optimizing Compilers for 586/686 machines" dans la section "Useful Pointers", merci à SSuummiitt RRooyy · Correction, "Asus P/I-UP5" est en fait "Asus P/I-P65UP5" vv00..3333,, 33 jjuuiinn 11999988 · Encore une success story avec une carte mère GigaByte DLX. · Une astuce pour les cartes mère Tyan, désactiver l'option "DRAM Fast Leadoff" du BIOS vv00..3322,, 2277 mmaaii 11999988 · Asus P/I-UP5 ajouter à la section carte-mère-sans-aucun-problème vv00..3311,, 1188 mmaaii 11999988 · Elitegroup P6LX2-A marche avec le 2.1.100 et le 101 · Les bugs doivent être rapportés àlinux-smp@vger.rutgers.edu vv00..3300,, 1122 mmaaii 11999988 · SuperMicro est maintenant une carte mère dans la section carte- mère-sans-aucun-problème vv00..2299,, 1111 mmaaii 11999988 · La success story d'une carte mère GigaByte 686 avec le 2.1.101 · Ajout d'un nouvel item dans la section "Coté utilisateur" : "Il y existe-t-il des programmes ou des library utilisant les threads ?" · La library OpenGL Mesa library est en train de passer au multithread. Cool! Voir la nouvelle section pour plus de détails. vv00..2288,, 0099 mmaaii 11999988 · Un miroir US de cette FAQ est maintenant disponible (voir Introduction) · Fusion de deux entrées confuses, Gigabyte 686 vv00..2277,, 0055 mmaaii 11999988 · Nouvelles informations pour les pilotes Adaptec et TekRam · Les cartes mères Micronics W6-LI marche avec SMP 1100.. LLiissttee ddeess ccoonnttrriibbuutteeuurrss De grand merci à ceux qui m'ont aider à maintenir ce HOWTO: 1. Tigran A. Aivazian 2. John Aldrich 3. Niels Ammerlaan 4. H. Peter Anvin 5. Guylhem Aznar 6. Ralf Bächle 7. James Beard 8. Troy Benjegerdes 9. Anton Blanchard 10. Emil Briggs 11. Robert G. Brown 12. Alexandre Charbey 13. Michael Elizabeth Chastain 14. Samuel S. Chessman 15. Alan Cox 16. Andrew Crane 17. Cort Dougan 18. Mark Duguid 19. Stéphane Écolivet 20. Jocelyne Erhel 21. Jay A Estabrook 22. Byron Faber 23. Mark Garlanger 24. hASCII 25. Wade Hampton 26. Andre Hedrick 27. Claus-Justus Heine 28. Benedikt Heinen 29. Florian Hinzmann 30. Moni Hollmann 31. Robert M. Hyatt 32. Jeffrey H. Ingber 33. Richard Jelinek 34. Tony Kocurko 35. Geerten Kuiper 36. Martijn Kruithof 37. Doug Ledford 38. Kumsup Lee 39. Hank Leininger 40. Ryan McCue 41. Paul Mackerras 42. Cameron MacKinnon 43. Joel Marchand 44. David Maslen 45. Chris Mauritz 46. Jean-Francois Micouleau 47. David Miller 48. Ingo Molnar 49. Ulf Nielsen 50. Jakob Oestergaard 51. C Polisher 52. Matt Ranney 53. Daniel Roesen 54. Ulf Rompe 55. Jean-Michel Rouet 56. Volker Reichelt 57. Sean Reifschneider 58. Sumit Roy 59. Thomas Schenk 60. Terry Shull 61. Chris K. Skinner 62. Hans - Erik Skyttberg 63. Szakacsits Szabolcs 64. Jukka Tainio 65. Simen Timian Thoresen 66. El Warren 67. Gregory R. Warnes 68. Gero Wedemann 69. Christopher Allen Wing 70. Leonard N. Zubkoff