Linux SMP HOWTO <author>Enkh Tumenbayar, <tt/etumenba@ouray.cudenver.edu/ <date>v1.4, 9 july 2002 <abstract> Questo HOWTO esamina i principali problemi (e si spera le soluzioni) relativi alla configurazione di SMP sotto Linux. </abstract> <toc> <sect>Licenza This document is made available under the terms of the GNU Free Documentation License. You should have received a copy with it. If not, it is available online at http://www.fsf.org/licenses/fdl.html. <sect>Introduzione Linux funziona su macchine SMP (Symmetric Multi-Processors). Il supporto a SMP è stato introdotto con il kernel versione 2.0, e da allora viene migliorato costantemente. HOWTO manutenuto da Enkh Tumenbayar (<htmlurl name="etumenba@ouray.cudenver.edu" url="mailto:etumenba@ouray.cudenver.edu">). L'ultima edizione di questo HOWTO può essere trovata a <itemize> <item> <htmlurl url="http://ouray.cudenver.edu/~etumenba/smp-howto/" name="http://ouray.cudenver.edu/~etumenba/smp-howto/"> (USA) </itemize> Se si vuol contribuire a questo HOWTO, preferirei un file diff per la versione SGML. Se mi viene inviata un'email circa questo HOWTO, prego includere un tag tipo <tt>[Linux SMP HOWTO]</> nel campo <tt>Subject:</> della propria e-mail. Questo mi aiuta a ordinare automaticamente le mail (e si avrà una risposta più velocemente <tt>;)</>). Questo HOWTO è un miglioramento di <url name="first draft" url="http://www.ihoc.net/linux-smp-faq-draft.html"> fatto da <bf>Chris Pirih</bf> e manutenuto da <bf>David Mentre</bf>. Tutte le informazioni contenute in questo HOWTO sono fornite "così come sono". Tutte le garanzie, espresse, implicite o statutarie, concernenti l'accuratezza delle informazioni e dell'idoneità per ogni uso particolare sono con ciò specificatamente smentite. Mentre ogni sforzo è stato fatto per assicurare l'accuratezza delle informazioni contenute in questo HOWTO, l'autore non si assume responsabilità per errori o omissioni, o per danni risultanti l'uso delle informazioni contenute qui. <sect>Questioni relative ad ogni architettura <sect1>Lato Kernel <enum> <item> <bf>Linux supporta il multi-threading? Se si avviano due o tre processi, essi saranno distribuiti tra le CPU disponibili ?</bf> Si. I processi e i kernel-thread sono distribuiti tra i processori. I thread in user-space no. <item> <bf>che tipo di architecture sono supportate in SMP ?</bf> <descrip> <tag/From <bf>Alan Cox</bf>:/ SMP è supportato nel 2.0 su sistemi hypersparc (SS20, etc.) e macchine Intel 486, Pentium o superiori le quali sono Intel conformi a MP1.1/1.4. <bf>Richard Jelinek</bf> aggiunge: proprio adesso, i sistemi sono stati testati fino a 4 CPU e lo standard MP (e così Linux) teoricamente permette fino a 16 CPU. Il supporto SMP per macchine UltraSparc, SparcServer, Alpha e PowerPC è disponibile dal 2.2.x. <tag/From <bf>Ralf Bächle</bf>:/ MIPS, m68k e ARM non supportano SMP; gli ultimi due probabilmente mai. Ecco, ho intenzione di hackerare MIPS-SMP appena ho una box SMP ... </descrip> <item> <bf>SMP distribuisce i thread tra i processori o è la libreria quella incaricata di ciò ?</bf> (<bf>Matti Aarnio</bf>) Il modo in cui Linux implementa i thread è di trattarli alla schedulazione nello stesso modo come ogni altro processo - il thread condivide solo diverse risorse del processo originale; spazio di memoria, file descrittori. Vedere clone(2) per parte della spiegazione. <item> <bf>Come si fa un kernel Linux SMP ?</bf> La maggior parte delle distribuzioni non fornisce un kernel già pronto al SMP, ciò significa che si dovrà farne uno da se. Se non si è ancora mai compilato un proprio kernel, questo è un motivo per imparare come. La spiegazione di come fare un nuovo kernel va oltre lo scopo di questo documento; fare riferimento al Linux Kernel Howto per maggiori informazioni. (<bf>C. Polisher</bf>) Configurare il kernel e rispondere Y a CONFIG_SMP. Se si usa LILO, è pratico avere entrambe le immagini dei kernel SMP e non-SMP a disposizione. Editare /etc/lilo.conf per creare un'entrata per un'altra immagine del kernel chiamata "linux-smp" o simile. La prossima volta che si compila il kernel, quando si esegue un kernel SMP, editare linux/Makefile e modificare "MAKE=make" in "MAKE=make -jN" (dove N = numero di CPU + 1, o se si ha molta memoria o swap si può usare solo "-j" senza un numero). Sentirsi liberi di sperimentare con questo parametro. Certamente si dovrebbe cronometrare quanto dura ogni compilazione :-) Esempio: <code> make config time -v sh -c 'make dep ; make clean install modules modules_install' </code> Se si stesse utilizzando delle macchine Compaq conformi a MP occorerà impostare il sistema operativo nelle impostazioni del BIOS a "Unix" Nei kernel della serie 2.0 fino ma non incluso il 2.1.132, decommentare la riga <tt/SMP=1/ nel principale Makefile (<tt>/usr/src/linux/Makefile</>). Nella versione 2.2, configurare il kernel e rispondere "yes" alla domanda "Symmetric multi-processing support" (<bf>Michael Elizabeth Chastain</bf>). E abilitare il supporto al real time clock configurando l'elemento "RTC support" (nel menù "Character Devices") (da <bf>Robert G. Brown</bf>). Notare che l'inserimento del supporto RTC, per quanto ne so io, non previene realmente il problema conosciuto della deviazione del clock in SMP, ma abilitando questa caratteristica si previene il blocco quando viene letto il clock all'avvio. Una nota di <bf>Richard Jelinek</bf> dice anche che l'attivazione del Enhanced RTC è necessaria per far funzionare la seconda CPU (identificata) su alcune schede madri originali Intel. E (nel kernel x86) NON abilitare l'APM (advanced power management)! APM e SMP non sono compatibili, se è abilitato l'APM il proprio sistema quasi certamente avrà un crash (o almeno probabilmente <tt>;)</>) durante l'avvio (<bf>Jakob Oestergaard</bf>). <bf>Alan Cox</bf> lo conferma: 2.1.x disabilitare l'APM per le box SMP. Fondamentalmente l'APM non viene definito in presenza di sistemi SMP, e potrebbe accadere qualsiasi cosa. E (nel kernel x86) abilitare il supporto "MTRR (Memory Type Range Register)". Alcuni BIOS hanno bug da non attivare la memoria cache per il secondo processore. Il supporto MTRR contiene codice che risolve tale malconfigurazione del processore. Occorre ricompilare il proprio kernel e i moduli del kernel quando si passa alla modalità SMP. Ricordare di eseguire <tt>make modules</> e <tt>make modules_install</> (da <bf>Alan Cox</bf>). Se si prende un "module load error", probabilmente non si è ricompilato e/o re-installati i propri moduli. Anche con alcuni kernel 2.2.x le persone hanno riportato problemi quando modificando la compilazione dal SMP ritornando indietro (all'uni-processore). Per correggere questo, salvare il proprio file .config, eseguire make mrproper, restorare il proprio file .config, poi ricompilare il proprio kernel (make dep, etc.) (<bf>Wade Hampton</bf>). Non dimenticare di eseguire lilo dopo aver copiato il proprio kernel nuovo. Ricap: <code> make config # o menuconfig o xconfig make dep make clean make bzImage # o qualsiasi altra cosa si voglia # copiare l'immagine del kernel manualmente, poi eseguire LILO # o make lilo make modules make modules_install </code> <item> <bf>Come è possibile compilare un kernel Linux <bf>non</bf>-SMP ?</bf> Nella serie 2.0, <bf>commentare</bf> la riga <tt/SMP=1/ nel principale Makefile (/usr/src/linux/Makefile). Nelle serie 2.2, configurare il kernel e rispondere "no" alla domanda "Symmetric multi-processing support" (<bf>Michael Elizabeth Chastain</bf>). Si deve ricompilare il proprio kernel e i moduli del kernel quando si passa a una modalità SMP. Ricordare di eseguire <tt>make modules</> e <tt>make modules_install</> e ricordare poi di eseguire lilo. Vedere le note di sopra circa i possibili problemi di configurazione. <item> <bf>Come posso dire se funziona ?</bf> <verb> cat /proc/cpuinfo </verb> Typical output (dual PentiumII): <code> processor : 0 cpu : 686 model : 3 vendor_id : GenuineIntel [...] bogomips : 267.06 processor : 1 cpu : 686 model : 3 vendor_id : GenuineIntel [...] bogomips : 267.06 </code> <item> <bf>Quale è lo stato della conversione del kernel verso un locking a granularità più fine e il multithreading ?</bf> La versione del kernel Linux 2.2 ha la gestione dei segnali, interrupt e altri argomenti I/O con lock a granularità fine. Il resto viene gradatamente migrato. Tutta la schedulazione è compatibile a SMP. La versione del Kernel 2.3 (prossimo 2.4) ha realmente il lock a granularità fine. Nei kernel 2.3 l'uso del lock big kernel è praticamente scomparso, tutti i maggiori sottosistemi del kernel Linux sono pienamente condotti a thread: networking, VFS, VM, IO, block/page cache, scheduling, interrupt, segnali, etc. (<bf>Ingo Molnar</bf>) <item> <bf>Che cosa è cambiato tra i kernel 2.2.x e 2.4.x ?</bf> <bf>(Mark Hahn)</bf> In molte parti del kernel, c'è poca relazione tra il 2.2 e il 2.4. Uno dei maggiori cambiamenti è l'SMP - non solo il rivoluzioario lock a granularità fine, ma il radicale rinnovamento della VM, gestione della memoria, gestione degli interrupt che è fondamentalmente neanche imparentata al 2.2, cambiamenti nella rete abbastanza rivoluzionari (thread e zero-copy), etc. In breve, il 2.2 non utilizza l'hardware come fa il 2.4. <item> <bf>Linux SMP supporta le affinità di processore ?</bf> <descrip> <tag/Kernel Standard/ Si e No. Non c'è modo per forzare un processo in una specifica CPU ma lo scheduler linux ha un processore preferito per ogni processo, il quale tende a tenere i processi legati ad una specifica CPU. <tag/Patch/ Si. Guardare <url name="PSET - Processor Sets for the Linux kernel" url="http://isunix.it.ilstu.edu/~thockin/pset/">: <quote> Il successo di questo progetto è di fare un sorgente compatibile e una versione funzionalmente equivalente di pset (come definito da SGI - parzialmente rimosso dal loro kernel IRIX 6.4) per Linux. Questo abilita gli utenti a determinare su quale processore o insieme di processori può essere eseguito un processo. Possibili usi includono il forzare thread su processori separati, sincronizzazione, sicurezza (una CPU solo `root' ?) e probabilmente di più. </quote> E' focalizzato intorno la syscall sysmp(). Questa funzione prende un numero di parametri che determinano quale funzione è richiesta. Le funzioni includono: <itemize> <item> legare un processo/thread a una specifica CPU <item> ridurre la capacità di una CPU a eseguire alcuni processi <item> ridurre del tutto l'esecuzione di una CPU <item> forzare una cpu a eseguire o eseguire soltanto un processo (e i suoi figli) <item> rilevare informazioni circa lo stato di una CPU <item> creazione/distruzione di insiemi di processori, ai quali possono essere limitati dei processi </itemize> </descrip> <item> <bf>Dove dovrebbe essere riportato un bug di SMP ?</bf> Prego riportare i bug a <tt>linux-smp@vger.kernel.org</>. <item> <bf>E le prestazioni di SMP ?</bf> Se si vogliono calcolare le prestazioni del proprio sistema SMP, si possono eseguire alcuni test fatti da Cameron MacKinnon e disponibili a <htmlurl name="http://www.phy.duke.edu/brahma/benchmarks.smp" url="http://www.phy.duke.edu/brahma/benchmarks.smp">. Dare un'occhiata anche a quest'articolo di Bryant, Hartner, Qi e Venkitachalam che compara i kernel 2.2 e 2.3/2.4 UP e SMP : <url url="http://www.usenix.org/publications/library/proceedings/als2000/bryantscale.html" name="SMP Scalability Comparisons of Linux¨ Kernels 2.2.14 and 2.3.99"> (<bf>Ray Bryant</bf>) (Si trovarà una copia anche <url name="qui" url="bryantscale.pdf">) </enum> <sect1>Lato Utente <enum> <item> <bf>Occorre veramente l'SMP ?</bf> Se occorre chiederselo, probabilmente no. <tt/:)/ Generalmente, i sistemi multi-processori possono fornire migliori prestazioni di sistemi uni-processori, ma per rendersi condo di ogni guadagno occorre considerare molti altri fattori oltre al numero delle CPU. Per esempio, su un dato sistema, se il processore è generalmente inattivo per molto tempo a causa di una lenta unità a disco, allora questo sistema è "limitato nell'input/output", e probabilmente non avrà beneficio da un incremento di potenza di processo. Se, d'altro lato, un sistema ha molti processi in esecuzione simultaneamente, e l'utilizzo della CPU è molto alto, allora è probable realizzare incrementi delle prestazioni del sistama. Le unità a disco SCSI possono essere molto efficaci quando usate con processori multipli, a causa del modo un cui possono processare comandi multipli senza usare la CPU. (<bf>C. Polisher</bf>) <item> <bf>E' possibile avere le stesse prestazioni da 2 processori 300 MHz che da un processore 600 MHz ?</bf> Questo dipende dall'applicazione, ma molto probabilmente no. SMP aggiunge alcuni miglioramenti che una box con un uniprocessore più veloce non avrebbe (<bf>Wade Hampton</bf>). <tt/:)/ <item> <bf>Cosa succede alle prestazioni del display con cpu multiple ?</bf> Grazie a <bf>Samuel S. Chessman</bf>, ecco alcune comode utilità: <descrip> <tag/Modalità testo:/ <htmlurl name="http://www.cs.inf.ethz.ch/~rauch/procps.html" url="http://www.cs.inf.ethz.ch/~rauch/procps.html"> Fondamentalmente, è procps v1.12.2 (top, ps, et. al.) e alcune patch per supportare SMP. Per il 2.2.x, <bf>Gregory R. Warnes</bf> ha fatto una patch disponibile a <htmlurl name="http://queenbee.fhcrc.org/~warnes/procps" url="http://queenbee.fhcrc.org/~warnes/procps"> <tag/Grafica:/ xosview-1.5.1 supporta SMP. E nei kernel prima del 2.1.85 (incluso) supporta l'entrata cpuX nel file /proc/stat. La homepage ufficiale per xosview è: <htmlurl url="http://lore.ece.utexas.edu/~bgrayson/xosview.html" name="http://lore.ece.utexas.edu/~bgrayson/xosview.html"> Sarà possibile trovare una versione con patch per i kernel 2.2.x di <bf>Kumsup Lee</bf> : <htmlurl url="http://www.ima.umn.edu/~klee/linux/xosview-1.6.1-5a1.tgz" name="http://www.ima.umn.edu/~klee/linux/xosview-1.6.1-5a1.tgz"> </descrip> A proposito, non è possibile monitorare precisamente la schedulazione del processore con xosview, perché xosview stesso causa una perturbazione della schedulazione. (<bf>H. Peter Anvin</bf>) E <bf>Rik van Riel</bf> dice il perché: <quote> La risposta è molto semplice. Fondamentalmente ci sono 3 processi implicati: <enum> <item> l'hog di cpu (priorità di schedulazione bassa perché mangia CPU) <item> xosview <item> X </enum> L'hog di CPU è in esecuzione su una CPU. Quindi xosview si avvia (sull'altra CPU) e inizia a mandare comandi a X, il quale si avvia pure. Dal momento che entrambi X e xosview hanno una più alta priorità del hog di CPU, xosview sarà eseguito su una CPU e X sull'altra. Poi xosview ferma l'esecuzione e si ha una CPU inattiva --> Linux sposta l'hog di CPU sulla nuova CPU inattiva (X è ancora in esecuzione sulla CPU dove prima era in esecuzione l'hog). </quote> <item> <bf>Come si può abilitare più di 1 processo per la propria compilazione del kernel ?</bf> usare: <code> # make [modules|zImage|bzImages] MAKE="make -jX" dove X=massimo numero di processi. ATTENZIONE: Questo non funziona per "make dep". </code> Con un kernel tipo 2.2, vedere anche il file <tt>/usr/src/linux/Documentation/smp.txt</> per istruzioni specifiche. BTW, il fatto che vengono eseguiti compilatori multipli permette ad una macchina con sufficente memoria di usare il tempo di CPU altrimenti perso durante i ritardi causati dagli I/O, <tt>make MAKE="make -j 2" -j 2</> in realtà aiuta anche su box con uniprocessore (da <bf>Ralf Bächle</bf>). <item> <bf>Come mai il tempo fornito dal comando <tt>time</> non è accurato ?</bf> (da <bf>Joel Marchand</bf>) Nelle serrie 2.0, il risultato fornito dal comando <tt>time</> è falso. La somma utente+sistema è giusta *ma* la ripartizione del tempo tra utente e sistema è falsa. Più precisamente: "La spiegazione è, che tutto il tempo di cpu speso dai processori tranne all'avvio è conteggiato come tempo di sistema. Se si tempifica un programma, sommare il tempo utente al tempo di sistema, allora il conteggio sarà quasi correto, eccetto anche l'inclusione del tempo di sistema che viene correttamente conteggiata" (<bf>Jakob Østergaard</bf>). Il bug è coretto nel kernel 2.2. </enum> <sect1>Programmazione SMP Sezione di <bf>Jakob Østergaard</bf>. Questa sezione è intesa per delineare cosa funziona, e cosa no quando si va a programmare software multi-thread per Linux SMP. <sect2>Metodi di parallelizazione <enum> <item> POSIX Thread <item> PVM / MPI Message Passing Libraries <item> fork() -- processi Multipli </enum> Dal momento che entrambi i processi fork() e PVM/MPI usualmente non condividono la memoria, ma o comunicano per mezzo del IPC o ottraverso messaggi API, essi non saranno descritti ulteriormente in questa sezione. Essi non sono molto specifici di SMP, dal momento che sono molto usati o altrettanto - o di più - su computer uniprocessori, e da ciò cluster. Solo POSIX Thread ci fornisce la condivisione di risorse in thread come - specialmente - la memoria. Questa è la cosa che rende una macchina SMP speciale, permettendo a molti processori di condividere la loro memoria. Per usare entrambi (o più ;) processori di un SMP, usare una libreria kernel-thread. Una buona libreria è la <url name="LinuxThread, una libreria pthread fatta da Xavier Leroy" url="http://pauillac.inria.fr/~xleroy/linuxthreads/"> la quale è adesso integrata con glibc2 (ovvero libc6). Le distribuzioni Linux più nuove includono questa libreria di default, quindi non si deve aquisire alcun pacchetto separato per usare i kernel thread. Ci sono implementazioni di thread (e thread POSIX) che sono a livello di applicazione, e non hanno i vantaggi del kernel-threading. Quesi pacchetti thread tengono il threading in un singlolo processo, quindi non hanno i vantaggi dell'SMP. Comunque, sono buoni per molte applicazioni e su sistemi a processore singolo tendono di fatto a eseguire più velocemente dei kernel-thread. . Comunque il multi-threading non è mai stato veramente popolare nel mondo UN*X. Per alcuni motivi, le applicazioni richiedono processi multipli o thread, di solito sono state scritte usando fork(). Perciò, quando si usa l'approccio thread, uno incorre in problemi di incompatibilità (non thread-ready) di librerie, compilatori, e debugger. GNU/Linux non fa eccezione a questo. Fiduciosamente le prossime sezioni faranno un pò di luce su cosa è attualmente possibile, e cosa no. <sect2>La libreria C Le vecchie librerie C non sono thread-compatibili. E' molto importante che si usi la GNU LibC (<bf>glibc</bf>), anche conosciuta come <bf>libc6</bf>. Certamente è possibile usare le prime versioni, ma questo causerà molti più problemi che aggiornare il proprio sistema, molto probabilmente :) Se si vuole usare GDB per eseguire il debug dei propri programmi, vedere di seguito. <sect2>Linguaggi, Compilatori e debugger C'è una ricchezza di linguaggi di programmazione disponibili per GNU/Linux, e molti di loro possono essere fatti per usare thread in un modo o nell'altro (alcuni linguaggi tipo Ada e Java hanno anche i thread come istruzioni primitive nel linguaggio). Questa sezione, comunque, descriverà al momento solo il C e il C++. Se si ha esperienza in programmazione SMP con altri linguaggi, prego renderlo noto. GNU C e C++, così come i compilatori EGCS C e C++ lavorano con il supporto ai thread dalla libreria standard C (<bf>glibc</bf>). Ci sono cpmunque alcuni problemi: <enum> <item> Quando si compila in C o C++, usare la define <bf>-D_REENTRANT</bf> nella riga di comando del compilatore. Questo è necessario per accertarsi che le funzioni error-handling funzionino così come la variabile errno. <item> Quando si usa C++, Se due threads hanno eccezioni simultaneamente, il programma avrà un segfault. Il compilatore non genera codice di eccezione thread-compatibile. La soluzione è di inserire un pthread_mutex_lock(&global_exception_lock) nel costruttore(i) di ogni classe throw(), e mettere il corrispondente pthread_mutex_unlock(...) nel distruttore. E' brutto, ma funziona. Questa soluzione è stata data da <bf>Markus Ferch</bf>. </enum> Il Debugger GNU <bf>GDB</bf> a partire dalla versione 4.18, dovrebbe gestire i thread correttamente. La maggior parte delle distribuzioni Linux offrono un gdb con patch pronto per i thread. Non è necessario applicare obbligatoriamente patch a <bf>glibc</bf> solo per farlo lavorare con i thread. Se non occorre eseguire debug al software (questo potrebbe essere vero per tutte le macchine che non sono workstation di sviluppo), non c'è bisogno di patch a <bf>glibc</bf>. Notare che i core-dump sono inutili quando si usano multipli thread. In qualche modo, il core dump viene legato a uno dei thread attualmente in esecuzione, e non al programma nella sua interezza. Perciò, ognivolta che si esegue il debug di qualsiasi cosa, eseguirlo dal debugger. <bf>Suggerimento:</bf> Se si ha un thread impazzito, tipo che mangia il 100% del tempo di CPU, e non si capisce il perché, ecco un modo carino per trovare cosa stà accadendo: Eseguire il programma direttamente dalla shell, non da GDB. Lasciare che il thread impazzisca. Usare <bf>top</bf> per rilevare il PID del processo. Eseguire GDB tipo <bf>gdb pid del programma</bf>. Questo farà collegare GDB stesso al processo con il PID che si è specificato, e arresterà il thead. Adesso si ha una sessione GDB con il thread dannoso, e si può usare <bf>bt</bf> e simili per vedere cosa stava accadendo. <sect2>Altre librerie <bf>ElectricFence:</bf> Questa libreria non è thread-compatibile. Questo dovrebbe essere possibile, comunque, per farla funzionare in ambienti SMP inserendo mutex-lock nel codice di ElectricFence. <sect2>Altri punti circa la programmazione SMP <enum> <item> <bf>Dove è possibile trovare moggiori informazioni circa la programmazione parallela ?</bf> Guardare a <url name="Linux Parallel Processing HOWTO" url="http://yara.ecn.purdue.edu/~pplinux/PPHOWTO/pphowto.html"> Molte utili informazioni possono essere trovate a <url name="Parallel Processing using Linux" url="http://yara.ecn.purdue.edu/~pplinux/"> Guardare anche il <url name="Linux Threads FAQ" url="http://linas.org/linux/threads-faq.html"> <item> <bf>Ci sono degli altri programi thread o librerie ?</bf> Si. Per i programmi, si dovrebbe guardare a: <url name="Multithreaded programs on linux" url="http://www.informatik.uni-bremen.de/~hollow/mthread.html"> (Amo hyperlink, lo conoscete ? <tt>;)</>) Per quanto riguarda le librerie, ci sono: <descrip> <tag/OpenGL Mesa library/ Grazie a <bf>David Buccarelli</bf>, <bf>Andreas Schiffler</bf> e <bf>Emil Briggs</bf>, esiste in versione multithread (ora [1998-05-11], c'è una versione funzionante che fornisce incremento di velocità del 5-30% su alcuni benchmark OpenGL). Il materiale multithread è adesso incluso nella regolare distribuzione Mesa come un'opzione sperimentale. Per maggiori informazioni, guardare il <url name="Mesa library" url="http://www.ssec.wisc.edu/~brianp/Mesa.html"> <tag/BLAS/ <url name="Pentium Pro Optimized BLAS and FFTs for Intel Linux" url="http://www.cs.utk.edu/~ghenry/distrib/"> Le routine BLAS Multithread non sono disponibili adesso, ma una libreria dual proc è pianificata per il 1998-05-27, vedere <url name="Blas News" url="http://www.cs.utk.edu/~ghenry/distrib/blasnews"> per dettagli. <tag/The GIMP/ <bf>Emil Briggs</bf>, la stessa persona che è coinvolta nel multithread Mesa, lavora anche sul plugin multithread di GIMP. Vedere a <htmlurl name="http://nemo.physics.ncsu.edu/~briggs/gimp/index.html" url="http://nemo.physics.ncsu.edu/~briggs/gimp/index.html"> per maggiori informazioni. </descrip> </enum> <sect1>Supporto di Specifica MultiProcessore (MPS) (<bf>Randy Dunlap</bf>) Linux supporta MPS (MP spec.) versione 1.1 e 1.4. Linux non ha il pieno supporto per tutta la versione 1.4 di MPS. L'esperienza ha mostrato che Linux di solito funziona meglio quando il BIOS è configurato per MP Spec. versione 1.1 se c'è un'opzione nel proprio BIOS di sistema. Non vedo perché la versione di MP Spec. dovrebbe importare a Linux, ma sarebbe un'esercizio interessante scoprire le differenze come presentato dalle tabelle del BIOS, per determinare perché Linux fallisce in alcuni casi con MP Spec. versione 1.4, e correggere Linux in modo che questo non abbia importanza. Questo documento riassume le maggiori modifiche in MP spec. versione 1.4 e il loro stato di supporto in Linux. <sect2> Symmetric I/O Mode (Modalità Simmetrica I/O) L'hardware deve supportare una modalità di operazione in cui il sistema può cambiare facilmente alla modalità Symmetric I/O alla PIC o alla modalità Virtual-Wire. Quando il sistema operativo è pronto per cambiare all'operazione MP, esso scrive un 01H sul registro IMCR, se quel registro è implementato, e abilita l'entrata della tabella di redirezione APIC I/O. L'hardware non deve richiedere nessun'altra azione sulla parte del software per fare la transizione alla modalità Symmetric I/O. Linux riconosce e supporta questa modalità di configurazione MP. <sect2> Floating Point Exception Interrupt (interrupt di eccezione di virgola mobile) Per la compatibilità PC/AT, il processore di bootstrap deve supportare la compatibilità DOS esecuzione FPU e gestione delle eccezioni mentre funziona in una delle modalità PC/AT-compatibili. Questo significa che i segnali di errore virgola mobile dal BSP devono essere ruotati al segnale 13 di richiesta di interrupt, IRQ13, quando il sistema è in modalità PIC o virtual wire. Mentre i segnali di errore virgola mobile da un processore di applicazione non deve essere ruotato al IRQ13, i progettisti di piattaforme possono scegliere di connettere i due. Per esempio, connettendo il segnale di errore virgola mobile dal processore di applicazione all'IRQ13 può essere utile in caso di una piattaforma che supporta la scelta dinamica di BSP durante l'avvio. In modalità simmetrica, un sistema conforme supporta solo unità a virgola mobile su chip, con segnalazione di errore attraverso interrupt vector 16. I sistemi operativi devono usare interrupt vector 16 per gestire le eccezioni di virgola mobile quando il sistema è in modalità simmetrica. Linux non usa affatto l'interrupt di virgola mobile ad eccezione nei sistemi a processore genuine-i386 i quali non sono SMP-capable. [In questi sistemi, se essi cablano la FPU-exception-line nel modo PC/AT-compatibile, viene eseguito un controllo durante l'esecuzione per la disponibilità del #MF-exception. Se l'#MF-exception è disponibile, allora Linux gestisce questo interrupt se capita. (<bf>Maciej W. Rozycki</bf>) <sect2> Configurazioni multiple APIC I/O Multiple APIC I/O sono supportate in Linux. <sect2> Tabella di configurazione MP Questa tabella è resa opzionale nella versione 1.4 di MPS. Se la tabella non è presente, dovrebbe essere usata una delle configurazioni di default. Inoltre è stata aggiunta ad essa una sezione estesa per i nuovi tipi di entrate della tabella. Linux supporta la Tabella di configurazione opzionale di MP e usa una configurazione di default se questa Tabella non è presente. Linux tollera le entrate della tabella nella sezione estesa saltandole se non vengono trovate. I dati delle entrate della tabella estesa non sono usati. <sect2> Campi Header della tabella di configurazione MP Campi nuovi o modificati per la versione 1.4 di MP Spec.: <itemize> <item> OEM Table Pointer: supportata in Linux <item> Extended Table Length: supportata (tollerata, saltata) in Linux <item> Extended Table Checksum: supportata (tollerata, saltata) in Linux </itemize> <sect2> Entrate estese della tabella di configurazione di MP Sono definiti i tipi di entrata per System Address Space Mapping (mappatura dell'indirizzo di spazio di sistema), Bus Hierarchy Descriptor (descrittore gerarchico di bus), e Compatibility Bus Address Space Modifier (modificatore di indirizzo di spazio compatibilità bus). Linux salta (non utilizza) queste entrate estese della tabella di configurazione di MP. Apparentemente questo non è critico a nessun sistema di trasporto. <sect>domande specifiche dell'architettura x86 <sect1>Perchè non funziona sulla mia macchina ? <enum> <item> <bf>Posso usare la mia CPU Cyrix/AMD/non-Intel con SMP ?</bf> Si. Gli attuali processori AMD Athlon MP supportano SMP con il chipset AMD 760MP. Ci sono diverse schede madri disponibili che dispongono di questo chipset, es. la Tyan, ASUS, etc. Athlon/SMP è supportato dai recenti kernel 2.4.x e anche dai vecchi kernel 2.2.x. (<bf>David Haring</bf>) <item> <bf>Perchè il mio vecchio Compaq non funziona ?</bf> Metterlo nella modalità conforme a MP1.1/1.4. controllare "Configure Hardware" -> "View / Edit details" -> "Advanced mode" (F7 penso) per l'opzione di configurazione "APIC mode" e impostarla a "full Table mode". Questa è una raccomandazione ufficiale Compaq. (<bf>Daniel Roesen</bf>) (<bf>Adrian Portelli</bf>)Fare questo: <enum> <item> Premere F10 quando il server si avvia per entrare nell'utilità di configurazione del sistema <item> Premere Enter per chiudere lo splash-screen <item> Immediatamente premere CTRL+A <item> Apparirà un messaggio che informa che si è in "Advanced Mode" <item> Poi selezionare "Configure Hardware" -> "View / Edit details" <item> Si vedranno le impostazioni avanzate (mischiate ad alcune ordinarie) <item> Andare a "APIC Mode" e selezionare "Fully Mapped" <item> Salvare le modifiche e riavviare </enum> <item> <bf>Non posso far funzionare il mio Compaq SystemPro in modalità SMP.</bf> (<bf>Maciej W. Rozycki</bf>) E' possibile che il proprio Compaq non usi il 82489DX APIC dal momento che furono introdotti più tardi -- a fine 1992 o ai primi del 1993. Erano macchine i486 che implementavano l'architettura APIC. 82489DX è il chip che veniva usato per queste e conteneva un'unità locale APIC e un unità APIC I/O. <item> <bf>Perchè il mio ALR non funziona ?</bf> Da <bf>Robert Hyatt</bf> : La ALR Revolution quad-6 sembra abbastanza sicura, mentre alcune macchine più vecchie revolution-quad senza processori P6 sembrano "incerte"... <item> <bf>Perchè SMP va così lento ?</bf> oppure <bf>Perchè una CPU mostra un valore molto bassi di bogomips mentre la prima è normale ?</bf> Da <bf>Alan Cox</bf>: Se una delle proprie CPU riporta un valore bogomips molto basso su essa la cache non è abilitata. Il venditore probabilmente ho fornito un BIOS bacato. Prelevare la patch per risolvere o meglio riportalo indietro e comprare una scheda da un venditore competente. Un kernel 2.0 (> 2.0.36) contiene la pacth MTRR la quale dovrebbe risolvere questo problema (selezionare l'opzione "Handle buggy SMP BIOSes with bad MTRR setup" nel menù "General setup"). Penso che la gestione di BIOS SMP bacati sia automatica negli ultimi kernel 2.2. <item> <bf>Ho sentito che macchine IBM hanno problemi</bf> Alcune macchine IBM hanno MP1.4 bios block nell'EBDA, permesso ma non supportato sotto i kernel 2.2. C'è un vecchia box IBM basata sul 486SLC. Linux/SMP richiede il supporto FPU hardware. <item> <bf>Ci sono vantaggi dell'Intel MP 1.4 su specifiche 1.1 ?</bf> No (secondo Alan <tt/:)/ ), 1.4 è solo un 1.1 con maggiori specifiche. Prego vedere <url name="Useful Pointers" url="SMP-HOWTO-8.html"> per la comparazione tra MP 1.4 e 1.1. <item> <bf>Perchè l'orologio devia così rapidamente quando eseguo linux SMP ?</bf> Questo è un problema conosciuto con la gestione degli IRQ e i lunghi lock del kernel nelle serie 2.0 dei kernel. Considerare l'aggiornamento agli ultimi kernel 2.2. Da <bf>Jakob Oestergaard</bf>: O, considerare l'esecuzione di xntpd. Che dovrebbe mantenere il proprio orologio al tempo corretto. (Penso di aver sentito che abilitando RTC nel kernel corregga anche il difetto dell'orologio. Per me funziona! ma non sono sicuro se è generale o se sono solo stato fortunato) Ci sono alcune correzioni del kernel nelle ultime serie 2.2.x che possono correggere questo. <item> <bf>Perchè le mie CPU sono numerate 0 e 2 invece di 0 e 1 (o altra strana numerazione) ?</bf> Il numero della CPU è assegnao dal produttore MB e non significa nulla. Ignorarlo. <item> <bf>Il mio sistema quad-Xeon rimane sospeso appena ha decompresso il kernel</bf> (<bf>Doug Ledford</bf>) Provare a ricompilare LILO con il supporto a LARGE_EBDA e poi assicurarsi di usare sempre make bzImage quando si compila il kernel. Il blocco all'avvio SMP su schede Intel multi-Xeon sembra essere stato corretto. Comunque, notare che anche questo sembra interrompere LILO in quanto l'opzione root= non funziona più, così assicurarsi di eseguire rdev della propria immagine del kernel e allo stesso tempo eseguire lilo per assicurarsi che il kernel carichi il corretto filesystem di root all'avvio. (<bf>Robert M. Hyatt</bf>) Con 3 cpu, occorre un terminatore nel 4° slot ? <item> <bf>Durante l'avvio della macchina rimane la segnalazione di avvertenza di un "unexpected IO-APIC"</bf> <bf>Risposta breve:</bf> Modificare la propria impostazione MP da 1.4 a 1.1 (opzione del BIOS), e avviare con l'opzione "noapic" al prompt dell'avvio. <bf>Risposta lunga:</bf> Questo messaggio non ha niente a che fare con i propri problemi di prestazioni o perché tutti gli interrupt vanno su una CPU. Questo messaggio è per i manutentori di ACPI(IO-APIC) di prestare attenzione a quando esce nuovo hardware. (<bf>Earle Nietzel</bf>) Per riassumere l'articolo trovato nella documentazione ufficiale del kernel: <enum> <item> L'"unexpected IO-APIC" è solo un indicatore che la propria scheda madre non è nella whitelist. <item> Eseguire un cat del proprio /proc/interrupts e se si vedono delle righe con IO-APIC allora va tutto bene perché gli IRQ di IO-APIC sono abilitati. </enum> <item><bf>Ho bisogno di modificare MP da 1.4 a 1.1 e avviare con (<bf>noapic</bf>) allo stesso tempo ?</bf> Dipende. Ho trovao che non occorre mettere off IO-APIC se si è cambiato da MP 1.4 a 1.1. Apparentemente alcune schede basate su Xeon hanno bisogno di entrambe, ma non le schede ASUS CUV4X. Mettendo off il supporto a IO-APIC non necessariamente impone una probabile penalizzazione in minori prestazioni ai proprietari di ASUS. (<bf>Vladimir G. Ivanovic</bf>) Alcune macchine IBM Netfinity avranno problemi di inizializzazione del controller SCSI integrato se è selezionato MPS 1.1. Ogni possibile LUB di ogni possibile dispositivo su ogni possibile bus sarà interrogato con un timeout. L'avvio avviene con un vano lungo tempo. (<bf>E. Robert Bogusta</bf>) Ci sono rapporti che sistemi con schede madri ASUS4X-DLS vanno bene con IO-APIC abilitato con MP 1.4. Per schede madri CUV4X-D, disabilitando i controller IDE probabilmente si può avviare con MP 1.4 e APIC abilitato. <item><bf>C'è caduta di prestazioni eseguendo "noapic" ?</bf> (<bf>David Mentre</bf>) Ha un impatto secondario, eccetto se si ha un alto carico di interrupt (es., quasi nessuno). <item> <bf>La mia schedamadre è una ASUS-CUV4X-DLS con il chipset VIA 694XDP. Se avvio con il flag noapic, la macchina si avvia bene e /proc/cpuinfo mostra entrambi i processori. Comunque, /proc/interrupts non mostra nessuna condivisione di interrupt.</bf> Probabilmente occorre aggiornare la propria versione di BIOS alla 1010. <item> <bf>Quali sono i pro e contro tra Xeon vs. Athlon ?</bf> Il chipset di Xeon (440GX) e la scheda madre relativa (supermicro S2DGE) che ho usato sono probabilmente (troppo ?) più affidabili e meglio supportati sotto Linux SMP che l'Athlon (AMD 760/760MP) semplicemente perché sono passati attraverso una più lunga sperimentazione. La cache più grande dello Xeon (1mb sul dual 400 che si stà considerando) può dare un miglioramento delle prestazioni (e dato che non ho pianificato di eseguire su questo solo del singolo codice scientifico, non è probabilmente utile testare benchmark specificamente per il mio codice). L'Athlon significativamente ha una frequenza di clock più alta (con la cache L2 full-speed L2 in Thunderbird, anche se solo 384kb) e più alta larghezza di banda di memoria con memorie PC2100 DDR che può aiutare molto. Il costo non è chiarito fino al rilascio della scheda 760MP e delle memorie PC2100, ma sarà probabilmente ~$950 per avere due 1GHz 385km L2 Thunderbirds, scheda madre dual e 512mb di ECC PC2100 vs ~$750 per avere due 400MHz 1mb L2 Xeon, scheda madre dual e 512mb di ECC PC100. (<bf>Daniel Freedman</bf>) <item><bf>Il mio sistema si blocca durante notevole traffico NFS</bf> Provare gli ultimi kernel 2.2.x e le patch knfsd. Questo è al momento sotto indagine. (<bf>Wade Hampton</bf>) <item> <bf>Il mio sistema si blocca senza alcun messaggio oops (avvertimento di errore interno del kernel)</bf> Se si stà usando kernel 2.2.11 o 2.2.12, prendere l'ultimo kernel. Per esempio 2.2.13 ha un certo numero di correzioni a SMP. Diversa gente ha riportato che questi kernel sono instabili per SMP. Questi stessi kernel possono avere problemi con NFS e possono causare blocchi. Può essere utile usare anche una console seriale per catturare i propri messaggi oops. (<bf>Wade Hampton</bf>) Se il problema resta (e gli altri suggerimenti in questa lista non aiutano altrimenti), allora si possono provare gli ultimi kernel 2.3. Essi hanno codice SMP/APIC più verboso (e più robusto), e codice automatico di prevezione dei lock hardware il quale produrrà significativi oops invece di una silenziosa esposizione. (<bf>Ingo Molnar</bf>) (<bf>Osamu Aoki</bf>) Si DEVONO anche disabilitare tutte le caratteristiche del BIOS relative al risparmio di energia. Un esempio di buona configurazione (Dual Celeron 466 Abit BP6): <code> POWER MANAGEMENT SETUP. ACPI: Disabled POWER MANAGEMENT: Disabled PM CONTROL by APM: No </code> Se le caratteristiche della gestione di energia sono attivate, possono capitare casuali blocchi del sistema. <item> <bf>Debug dei blocchi</bf> (articolo di <bf>Wade Hampton</bf>) Un buon mezzo per fare debug dei blocchi è di prelevare la patch ikd da Andrea Arcangeli: <htmlurl url="ftp://ftp.suse.com/pub/people/andrea/kernel-patches/" name="ftp://ftp.suse.com/pub/people/andrea/kernel-patches"> Ci sono diverse opzioni di debug, ma NON usare l'opzione soft-lockup! Per le box più nuove, impostare il debug del kernel poi attivare il NMI oopser. Per verificare che l'NMI oopser stia funzionando, dopo aver avviato il nuovo kernel, <tt>/cat /proc/interrupts</> e verificare di avere le NMI. Quando la box si blocca, si dovrebbe ricevere un avviso. Si può anche provare l'opzione %eip. Questa permette al kernel di stampare alla console l'indirizzo %eip ogni volta che una funzione del kernel viene chiamata. Quando la box si blocca, annotare la prima colonna ordinata dalla seconda colonna poi cercare l'indirizzo nel file System.map. Questo funziona solo in modalità console. Notare anche che l'uso di una console seriale può facilitare assai nel debug dei blocchi del kernel, non solo per i blocchi del kernel SMP ! <item> <bf>Il messaggio nei log "APIC error interrupt on CPU#n, should never happen"</bf> Un messaggio tipo: <code> APIC error interrupt on CPU#0, should never happen. ... APIC ESR0: 00000002 ... APIC ESR1: 00000000 </code> indica una 'ricezione di errore di checksum'. Questo non può essere causato da Linux in quanto la parte di messaggi di checksum di APIC avviene completamente a livello hardware. Potrebbe essere un hardware marginale. Finchè non si nota alcuna instabilità, questi non sono problematici - i messaggi APIC sono riprovati fin tanto che non vengono rilasciati. (<bf>Ingo Molnar</bf>) </enum> <sect1>Possibili cause di crash In questa sezione si troveranno alcune <bf>possibli</bf> motivi di un crash di una macchina SMP (i ringraziamenti sono dovuti a <bf>Jakob Østergaard</bf> per questa parte). Per quanto sò (David), questi problemi sono specifici di Intel. <itemize> <item> <bf>Problemi di raffreddamento</bf> >Da <bf>Ralf Bächle</bf>: [Relativo alla dimensione del case e delle ventole] E' importante che l'aria circoli. Nauralmente non può nei cavi etc. questo è preventivato ad esempio nei case troppo piccoli. D'altra parte ho visto che anche sovradimensionando i case causa grossi problemi. Ci sono alcuni case tower sul mercato che realmente sono peggiori per il raffreddamento che dei desktop. In breve, la cosa giusta è pensare all'aerodinamica nel case. Sono pure utili dei case extra per periferiche molto calde. Sicuramente si può sempre andare su Radio Shack (o simile) e prendere un'altra ventola. Si può usate lm_sensors per monitorare la temperatura della CPU dei nuovi processori PII e PIII. Questo può aiutare a determinare se la temperatura è un problema. (<bf>Wade Hampton</bf>) <item> <bf>Memorie di scarsa qualità</bf> Non comprare RAM economiche e non usare moduli misti di RAM sulla scheda madre la quale è esigente su questo. Specialmente le schede madri Tyan sono rinomate per essere esigenti sulla velocità della RAM. Ci sono alcuni resoconti di RAM PC100 a 10ns vendute con schede madri dove la CPU realmente ha bisogno di RAM a 8ns. (<bf>Wade Hampton</bf>) <item> <bf>Cattive combinazioni di diversi livelli di CPU</bf> Controllare <tt>/proc/cpuinfo</> per vedere se le proprie CPU sono dello stesso livello. <item> <bf>Se il proprio sistema è instabile, allora NON overcloccatelo !</bf> ...e anche se fosse stabile, NON overcloccatelo. >Da <bf>Ralf Bächle</bf>: l'overclocking causa problemi molto subdoli. Ho degli esempi, una delle mie vecchie macchine overcloccate calcola male una coppia di pixels di un frattale 640 x 400. Il problema è visibile solo quando si comparano usando dei tool. Così è meglio dire mai, never, nuncas, jamais, niemals overcloccare. <item> <bf>Kernel 2.0.x e fast ethernet</bf> (da <bf>Robert G. Brown</bf>) I kernel 2.0.x su sistemi a alte prestazioni fast ethernet hanno significanti (e risaputi) problemi con una condizione di race/deadlock nella gestione degli interrupt di rete. La soluzione è di prendere l'ultimo driver di sviluppo 100BT da <url name="CESDIS Linux Ethernet device drivers site" url="http://cesdis.gsfc.nasa.gov/linux/drivers/"> (uno che definisce SMPCHECK). <item> <bf>Un bug nel chipset 440FX</bf> (da <bf>Emil Briggs</bf>) Se si ha un sistema che usa il chipset 440FX allora i propri problemi con i blocchi sono possibilmente dovuti a l'errata documentata del chipset. Ecco un riferimento Riferimenti: Intel 440FX PCIset 82441FX (PMC) e 82442FX (DBX) Aggiornamento delle specifiche. pg. 13 <htmlurl name="http://www.intel.com/design/pcisets/specupdt/297654.htm" url="http://www.intel.com/design/pcisets/specupdt/297654.htm"> Il problema può essere corretto con uno stratagemma nel BIOS (O una patch al kernel) e in fatti David Wragg ha scritto una patch che è inclusa alla patch MTTR di Richard Gooch. Per maggiori informazioni e correzioni vedere qui: <htmlurl name="http://nemo.physics.ncsu.edu/~briggs/vfix.html" url="http://nemo.physics.ncsu.edu/~briggs/vfix.html"> <item> <bf>NON eseguire emm386.exe prima di aver avviato linux SMP</bf> >Da <bf>Mark Duguid</bf>, regola sciocca #1 con schede madri W6LI. <tt>;)</> <item> <bf>Se queste macchine si riavviano o si bloccano dopo un pò, ci possono essere due buone ragioni relative al BIOS e alla memoria</bf> (da <bf>Jakob Østergaard</bf>) <itemize> <item> Se il BIOS ha l'impostazione tipo "memory hole at 16M" e/o "OS/2 memory > 64MB", provare a disinstallarle entrambe. Linux non reagisce sempre bene con queste opzioni. <item> Se si ha ua macchina con più di 64 MB di memoria, e si è specificato manualmente il numero esatto nella configurazione di LILO, si dovrebbe specificare un MB meno di quella che realmente si ha sulla macchina. Se si ha 128 MB, la propria riga di lilo.conf dovrebbe essere tipo: append="mem=127M" </itemize> <item> <bf>Essere consapevoli dei problemi relativi agli IRQ</bf> A volte, alcune schede non sono riconosciute o possono scatenare conflitti di IRQ. Provare a mischiare le schede negli slot in diffrerenti modi e possibilità spostandole in diversi IRQ. Contributo di <bf>hASCII</bf> : rimuovendo la riga " append="hisax=9,2,3"" in lilo.conf permette l'utilizzo di un kernel dalla serie 2.1.xx con il supporto attivato per ISDN e Hisax. I Kernel dalla serie 2.0.xx non hanno problemi come questo. Provare anche a impostare le opzioni di setup del BIOS tipo "MP 1.4 mode" o "route PCI interrupts through IOAPIC", o a non impostare l'"OS Type" a DOS o Novell (<bf>Ingo Molnar</bf>). <item> <bf>Accesso al floppy mentre l'audio è attivo</bf> Se avviene un blocco quando si prova ad accedere al floppy (per esempio mentre l'audio è in esecuzione) si può dover editare drivers/pci/quirks.c e impostare <tt>/int isa_dma_bridge_buggy = 1;</> Questo è un problema con il mio Dell WS400 dual PII/300, 2.2.x, SMP (<bf>Wade Hampton</bf>). </itemize> <sect1>Informazioni specifiche sulle schede madri Prego notare: Altre informazioni specifiche possono essere trovate attraverso la lista di <url name="Motherboards rumored to run Linux SMP" url="http://www.nlug.org/smp/"> <sect2>Schede madri con problemi conosciuti <itemize> <item> nessuno adesso </itemize> <sect1>Box Linux SMP a basso costo (box dual Celeron) (<bf>Stéphane Écolivet</bf>) Box Linux SMP aquistabili a più basso costo con processori di oggi giorno sono sistemi dual Celeron. Un tale sistema non è ufficialmente possibile secondo Intel. Meglio pensare alla seconda generazione di Celeron, quelli con 128 Kb di cache L2. <sect2>E' possibile far funzionare una box con dual Intel Celeron ? <bf>Risposta ufficiale da Intel:</bf> no, i Celeron non possono funzionare in modalità SMP. <bf>Risposta practica:</bf> è possibile, ma richiede un'alterazione hardware per i processori dello Slot 1. L'alterazione viene descritta da Tomohiro Kawada su questa pagina <url name="Dual Celeron System" url="http://kikumaru.w-w.ne.jp/pc/celeron/index_e.html">. Di certo, questo tipo di modifica rimuove la garanzia... Alcune versioni del processore Celeron sono disponibili anche per il formato Socket 370. In quel caso, l'alterazione può essere fatta solo sul Socket 370 all'adattatore dello Slot 1 o può anche essere venduto pre-cablato per l'uso SMP. (<bf>Andy Poling</bf>, <bf>Hans - Erik Skyttberg</bf>, <bf>James Beard</bf>) C'è anche una scheda madre (ABIT BP6) che permette di avere inseriti due Celeron nel formato Socket 370 (<bf>Martijn Kruithof</bf>, <bf>Ryan McCue</bf>). ABIT Computer BP6 verificati testati e nativi per linux con dual ppga socket 370 (<bf>Andre Hedrick</bf>). <sect2>Come si comporta Linux su un sistema dual Celeron ? Bene, grazie. <sect2>I processori Celeron sono risaputi essere facilmente overcloccabili. E i sistemi dual Celeron ? <bf>Possono</bf> funzionare. Comunque, overcloccare questo tipo di sistemi non è così semplice come overcloccarne uno mono-processore. Non è in definitiva una buona idea per un sistema di produzione. Per uso personale, i sistemi dual Celeron 300A viene riportato che eseguono rock-solid a 450 MHz. (<bf>da molte persone</bf>) <sect2>E fare un sistema quad Celeron ? E' impossibile. I processori Celeron hanno quasi le stesse caratteristiche dei chip base dei Pentium II. Se si vuole più di 2 processori nel proprio sistema, si dovrà cercare delle box Pentium Pro, Pentium II Xeon o Pentium III (?) . <sect2>Cosa dire circa il mix di processori Celeron e Pentium II ? Un sistema che usa un processore "ripristinato" Celeron e un processore Pentium II con lo stesso livello <bf>può teoricamente</bf> funzionare. <bf>Alexandre Charbey</bf> come è stato fatto un tale sistema: <itemize> <item> Scheda madre Asus P2B-D, proc. 1: Celeron 366, proc. 2: Pentium II 400@266 <item> frequenze di bus 66Mhz e 75Mhz dove funzionale <item> il processore più veloce (in questo caso il Celeron) dovrebbe essere messo sul secondo slot. Scambiando i processori (prima il più veloce) porta ad un rapido guasto. </itemize> <sect>Domande specifiche sull'architettura Sparc <sect1>Quali macchine Sparc sono supportate ? Citando la pagina web <url name="UltraLinux" url="http://ultra.linux.cz/"> (solo sistemi SMP): <itemize> <item> UltraSPARC basata PCI workstation: Ultra60, Ultra450 <item> UltraSPARC basata SBUS server: Enterprise 1, 2, 150 <item> UltraSPARC basata SBUS large server: Enterprise 3000, 4000, 5000, 6000, 10000 <item> UltraSPARC basata PCI server: Enterprise 250, 450 <item> SPARC sun4m macchine SMP (<bf>Anton Blanchard</bf>) <item> <url name="Starfire E10000" url="http://linuxcare.com.au/anton/e10000/"> </itemize> UltraLinux viene eseguito su una macchina a 14 CPU (vedere <url name="dmesg output" url="http://lwn.net/1998/1210/a/dm-sparc.html">) e su una Starfire E10000 con 24 CPU (vedere <url name="dmesg output" url="http://linuxcare.com.au/anton/e10000/dmesg_24.shtml">). Le SparcStation 10 e SparcStation 20 sono macchine capaci del SMP e in accordo con <url name="FAQABOSS" url="http://fagaboss.sunhelp.org"> le seguenti combinazioni sono risapute funzionare: <itemize> <item> 2xSM40 ( modello 402 ) <item> 2xSM41 ( modello 412 ) <item> 2xSM51 ( modello 512 ) <item> 2xSM512 ( modello 514 ) <item> 2xSM61 ( modello 612 ) <item> 2xSM71 ( modello 712 ) <item> 2xSM81 ( modello 812 ) </itemize> E, come dichiarato prima, i moduli CPU nelle SparcStation 10 e 20 possono eseguire diverse velocità di clock, le seguenti _DOVREBBERO_ funzionare: <itemize> <item> 2xSM50 <item> SM41, SM51 <item> SM41, SM61 <item> SM51, SM61 <item> SM71, SM81 </itemize> Come esegue ? Bene, è veloce, veramente veloce. Alcune delle Demo java possono essere eseguite più velocemente su un dual HyperSparc 125Mhz 128MB ( ywing ) che su un dual celeron BP6 433@433Mhz 192MB ( calimero ). Lo stesso si applica per Gimp. Quando si compila calimero esegue più velocemente che ywing. Entrambi i computer eseguono un kernel 2.2.16 e il sotto sistema di hard disk di calimero è tutto SCSI. Un'importante dettaglio quando si pianifica di avere diversi moduli CPU nel proprio computer è di avere lo stesso tipo di moduli, non si può mischiare SuperSparc e HyperSparc per esempio, ma si può avere un numero dispari di CPU, per esempio 3. E' stato detto di essere in grado di eseguire moduli a diversa velocità di clock come scritto in questo articolo da AcesHardware , ma non posso testimoniarlo. (<bf>Lionel, trollhunter Bouchpan-Lerus-Juery</bf>) <sect1>Problemi specifici relativi al supporto SMP per Sparc (<bf>David Miller</bf>) Non ci dovrebbe essere nessun problema. Il solo problema conosciuto, e il quale non si intende correggere, è che se si compila un kernel SMP per sistemi 32-bit (es. non-ultrasparc), questo kernel non funzionaerà su sistemi sun4c. <sect>Domande specifiche per architetture PowerPC <sect1>Quali macchine PPC sono supportate ? <itemize> <item> PowerSurge schede (incluso UMAX s900) <item> PowerMac <item> Motorola MTX: supporto in sviluppo. Patch non ancora integrate nel kernel principale (<bf>Troy Benjegerdes</bf>) </itemize> (<bf>Cort Dougan</bf>) Non supportati: sistemi PPC RS/6000 <sect1>Problemi specifici relativi al SMP PPC Niente. Compilazione SMP usuale (vedere sopra). Al solito, fare attenzione, i moduli sono specifici o per UP o SMP. Ricompilarli. (<bf>Paul Mackerras</bf>) <sect>Domande specifiche per archietetture Alpha <sect1>Quali macchine Alpha sono supportate ? (<bf>Geerten Kuiper</bf>) SMP funziona per la maggior parte, se no per tutti, dei server AXP. (<bf>Jay A Estabrook</bf>) SMP sembra funzionare sulla maggior parte delle nostre box [Compaq] con 2 o più CPU. Che includono : <itemize> <item> AS2000/2100 (SABLE) <item> AS4000/4100 (RAWHIDE) <item> DS20 (DP264) <item> GS320 (vedere <url name="bootlog for a 31 CPUs machine" url="http://lwn.net/daily/gs320.php3">) </itemize> Non include : <itemize> <item> AS2100A (LYNX) <item> TurboLaser bigboys (8200/8400) </itemize> (<bf>Alpha Processor Inc</bf>) il supporto all'SMP è stato qualificato per tutti i sistemi API SMP ad iniziare dal'ultima serie del kernel 2.2 (approssimativamente dal kernel 2.2.7). Al momento della redazione, è : <itemize> <item> DP264 <item> UP2000 </itemize> Vedere <url name="API's support website" url="http://www.alpha-processor.com/support/index.shtml"> per maggiori informazioni. <sect1>Problemi specifici relativi al suporto SMP su Alpha Nessuno (veramente ? :-) <sect>Link utili <sect1>Vari <itemize> <item> <url name="Parallel Processing usando Linux" url="http://yara.ecn.purdue.edu/~pplinux/"> <item> <url name="Linux Parallel Processing HOWTO" url="http://yara.ecn.purdue.edu/~pplinux/PPHOWTO/pphowto.html"> <item> linux-smp mailing list Per <bf>iscriversi</bf>, inviare <tt/subscribe linux-smp/ nel corpo del messaggio a <htmlurl url="mailto:majordomo@vger.kernel.org" name="majordomo@vger.kernel.org"> Per <bf>cancellarsi</bf>, inviare <tt/unsubscribe linux-smp/ nel corpo del messaggio a <htmlurl url="mailto:majordomo@vger.kernel.org" name="majordomo@vger.kernel.org"> <url name="Archivi Linux SMP" url="http://www.linuxhq.com/lnxlists/linux-smp/"> <url name="Archivi Linux SMP a progressive-comp.com" url="http://www.progressive-comp.com/Lists/?l=linux-smp&r=1&w=2#linux-smp"> <item> <url name="libreria pthread fatta da Xavier Leroy" url="http://pauillac.inria.fr/~xleroy/linuxthreads/"> <item> <url name="Schede madri risapute eseguire Linux SMP" url="http://www.nlug.org/smp/"> <item> <url name="procps" url="http://www.cs.inf.ethz.ch/~rauch/procps.html"> <item> <url name="procps patch per 2.2.x" url="http://queenbee.fhcrc.org/~warnes/procps"> <item> <url name="xosview" url="http://lore.ece.utexas.edu/~bgrayson/xosview.html"> <item> <url name="xosview for 2.2.x" url="http://www.ima.umn.edu/~klee/linux/xosview-1.6.1-5a1.tgz"> <item> <url name="Prestazioni SMP di Linux" url="http://www.phy.duke.edu/brahma/benchmarks.smp"> <item> <url name="sito CESDIS Linux Ethernet driver di dispositivi" url="http://cesdis.gsfc.nasa.gov/linux/drivers/"> <item> <url name="sistemi Dual Celeron" url="http://kikumaru.w-w.ne.jp/pc/celeron/index_e.html"> <item> <url name="LaTeX documento descrittivo implementazione di MultiProcessor Linux" url="http://www.linuxhq.com/kernel/v2.4/doc/smp.tex"> <item> <url name="IRQ affinità" url="http://www.linuxhq.com/kernel/v2.4/doc/IRQ-affinity.txt.html"> </itemize> <sect1> Progrtammi e librerie Multithread <itemize> <item> <url name="FAQ Linux Thread" url="http://linas.org/linux/threads-faq.html"> <item> <url name="programmi Multithread su linux" url="http://www.informatik.uni-bremen.de/~hollow/mthread.html"> <item> <url name="Ottimizzazioni Pentium Pro BLAS e FFT per Intel Linux" url="http://www.cs.utk.edu/~ghenry/distrib/"> (adesso non disponibile, ma una libreria dual proc. è prevista per il 5/27/98, vedere <url name="Blas News" url="http://www.cs.utk.edu/~ghenry/distrib/blasnews"> per dettagli) <item> <url name="Libreria Mesa" url="http://www.ssec.wisc.edu/~brianp/Mesa.html"> (con multi-threading sperimentale) <item> <url name="Plugin Parallelo per The GIMP" url="http://nemo.physics.ncsu.edu/~briggs/gimp/index.html"> </itemize> <sect1>Patch specifiche SMP <itemize> <item> <url name="Patch per un bug nel chipset 440FX" url="http://nemo.physics.ncsu.edu/~briggs/vfix.html"> <item> <url name="PSET - Processor Sets per kernel Linux" url="http://isunix.it.ilstu.edu/~thockin/pset/"> <item> <url name="Patch Ingo Molnar SMP" url="http://www.redhat.com/~mingo/"> (solo per esperti, prego leggere Linux-smp@vger.kernel.org) </itemize> <sect1> Parallelizzazione e ottimizzazione dei compilatori per macchine 586/686 (<bf>Sumit Roy</bf>) <itemize> <item> <url name="Pentium Compiler Group" url="http://www.goof.com/pcg/"> creatori per pgcc <item> <url name="Absoft" url="http://www.absoft.com/"> , Fortran 90 e Fortran 77 compilatori <item> <url name="The Portland Group, Inc." url="http://www.pgroup.com/">, supporto allo <url name="OpenMP" url="http://www.openmp.org"> standard per la parallelizzazione in Fortran su Linux <item> <url name="Pacific-Sierra Research Corporation" url="http://www.psrv.com/">, ha un compilatore F90 libero per Linux, così come compilatori paralleli per SMP Linux <item> <url name="Applied Parallel Research" url="http://s006.infomall.org/index.html">, al momento hanno compilatori paralleli per WinNT <item> <url name="KAI" url="http://www.kai.com"> ha un compilatore C++ per Linux, che comprende OpenMPI. E' chiamata Guide_OpenMP. Informazioni a <htmlurl name="http://www.kai.com/parallel/kappro/guide" url="http://www.kai.com/parallel/kappro/guide">. (<bf>Gero Wedemann</bf>) </itemize> <sect>Glossario <sect1>Definizioni <itemize> <item> <bf>SMP</bf> Symmetric Multi-Processor. <item> <bf>UP</bf> Uni-Processor: sistema con un processore. <item> <bf>APIC</bf> Advanced Programmable Interrupt Controler (controller avanzato di interrupt programmabile). <item> <bf>thread</bf> Un thread è un'attività del processore in un processo. Lo stesso processo può avere thread multipli. Questi thread condividono con il processo lo spazio indirizzato e possono perciò condividere i dati. <item> <bf>pthread</bf> Posix thread, (definizione di thread dagli standard Posix). <item> <bf>processo</bf> Un programma in esecuzione, con il proprio ambiente. <item> <bf>MTRR</bf> Memory Type Range Register (registro della gamma di tipologie di memoria) <item> <bf>APM</bf> Advanced Power Management (Gestione avanzata dell'energia). <item> <bf>FPU</bf> Floating Point Unit. Anche chiamato co-processore aritmetico. <item> <bf>IRQ</bf> Interrupt ReQuest (Richiesta di interruzione). <item> <bf>EBDA</bf> Extended BIOS Data Area (Area estesa di dati del BIOS). <item> <bf>ACPI</bf> Advanced Configuration and Power Interface (Configurazione avanzata e interfaccia energetica). <item> <bf>oops</bf> Internal kernel error (avviso di errore interno del kernel). <item> <bf>Cluster</bf> Gruppo di computer che realizzano un calcolo comune (conosciuto nella comunità Linux anche come Beowulf). </itemize> <sect1>Concetti <itemize> <item> <bf>Corse ai dati</bf> Una corsa ai dati accade quando i processi vogliono modificare una variabile condivisa simultaneamente senza proteggere loro stessi dagli effetti dell'altro processo. Poniamo A una variabile condivisa. Poniamo P1 e P2 due processi che accedono a questa variabile. Questi due processi stanno facendo la stessa seguente operazione: "leggere A in una variabile tmp (locale al processo); eseguire tmp = tmp + 1 ; scrivere tmp in A". Se la variabile A non è protetta da un lock, il risultato dell'esecuzione potrebbe non corrispondere a quello che ci si aspetta. Per esempio, ecco due esempi se non si esegue un lock su A: <verb> caso #1: A=0 P1: read A -> tmp1 (tmp1 è 0) P2: read A -> tmp2 (tmp2 è 0) P1: tmp1 = tmp1 + 1 (tmp1 è 1) P2: tmp2 = tmp2 + 1 (tmp2 è 1) P1: tmp1 -> write A (A è 1) P2: tmp2 -> write A (A è 1) </verb> <verb> caso #2: A=0 P1: read A -> tmp1 (tmp1 è 0) P1: tmp1 = tmp1 + 1 (tmp1 è 1) P1: tmp1 -> write A (A è 1) P2: read A -> tmp2 (tmp2 è 1) P2: tmp2 = tmp2 + 1 (tmp2 è 2) P2: tmp2 -> write A (A è 2) </verb> Per evitare questo tipo di problemi, si usa un lock: <verb> A=0: P1: lock A P1: read A -> tmp1 (tmp1 è 0) P2: lock A (P2 è bloccata) P1: tmp1 = tmp1 + 1 (tmp1 è 1) P1: tmp1 -> write A (A è 1) P1: unlock A (P2 è sbloccata) P2: read A -> tmp2 (tmp2 è 1) P2: tmp2 = tmp2 + 1 (tmp2 è 2) P2: tmp2 -> write A (A è 2) P2: unlock A </verb> <item> <bf>Deadlock</bf> Questo è un inter-bloccaggio che accade quando due processi vogliono accedere a variabili condivise reciprocamente bloccate. Per esempio, poniamo A e B due variabili bloccate e P1 e P2 due processi: <verb> P1: lock A P2: lock B P1: lock B (P1 è bloccato da P2) P2: lock A (P2 è bloccato da P1) </verb> Il processo P1 è bloccato perché stà aspettando lo sblocco della variabile B da P2. Comunque P2 ha bisogno anche della variabile A per terminare il suo calcolo e liberare B. Così si ha un deadlock. In questo esempio, il problema è molto semplice. Ma si immagini cosa possa accadere in 2 milioni di righe di codice (come il kernel linux) con centinaia di lock. :-) </itemize> <sect> Che c'è di nuovo ? <descrip> <tag/v1.14, 9 luglio 2002 <itemize> <item> Primo rilascio da almeno due anni <item> Aggiunto l'articolo Multiprocessor Specification Support (<bf>Randy Dunlap</bf>) <item> Aggiunto la spiegazione del problema "unexpected IO-APIC" <item> Aggiunta una nota sulle modifiche tra i kernel 2.2.x e 2.4.x <item> Aggiunto aggiornamento della sezione SPARC (<bf>Lionel, trollhunter Bouchpan-Lerust-Juery</bf>) <item> Aggiunte varie domane e risposte <item> Eliminato "SMP specific limit with current kernel (2.2)": obsoleto <item> Modifica parola "current" dai documenti del kernel 2.2 </itemize> <tag/v1.12.1, 25 ottobre 2000 <itemize> <item> Ineriti tutti gli autori da Bryant, Hartner, Qi e Venkitachalam </itemize> <tag/v1.12, 22 ottobre 2000 <itemize> <item> Spiegazione su perché non fidarsi di Xosview nella schedulazione (<bf>Rik van Riel</bf>) <item> Un link ad un articolo che compara i kernel 2.2 e 2.4 (<bf>Ray Bryant</bf>) </itemize> <tag/v1.11, 8 ottobre 2000 <itemize> <item> Linux si avvia su una Sun E1000 con 24 CPU <item> Linux si avvia su una AlphaServer con 31 CPU </itemize> <tag/v1.10, 5 ottobre 2000 <itemize> <item> Nuovo indirizzo mailing-list linux-smp: linux-smp@vger.kernel.org (me) <item> Dove trovare le impostazioni di RTC nel config del kernel (<bf>Patrick Doyle</bf>) <item> glossario aggiornato e aggiunti concetti (da una versione francese fatta da <bf>Ludovic Danigo</bf>) <item> Corretta un'incongruenza (<bf>Matthias Schniedermeyer</bf>) <item> Eliminati link errati (<bf>Johan Ekenberg</bf>) </itemize> <tag/v1.9.1, 28 settembre 2000 <itemize> <item> aggiornato con informazioni da <bf>Stig Telfer</bf> descriventi il supporto SMP su sistemi API Alpha </itemize> <tag/v1.9, 13 gennaio 2000 <itemize> <item> Ricordare di disabilitare tutte le caratteristiche di risparmio energetico del BIOS (<bf>Osamu Aoki</bf>) <item> Spiegazione su come accedere ai server Compaq in modalità di configurazione avanzata (<bf>Adrian Portelli</bf>) </itemize> <tag/v1.8, 8 novembre 1999 <itemize> <item> le schede madri quad-celeron erano uno scherzo, restorato il vecchio paragrafo (<bf>Simen Timian Thoresen</bf>) </itemize> <tag/v1.7, 6 novembre 1999 <itemize> <item> nuova introduzione (<bf>C. Polisher</bf> aka cp) <item> corretti numerosi errori di digitazione e grammaticali (cp) <item> paragrafo preliminare sulla compilazione del kernel (cp) <item> paragrafo preliminare sui requisiti di SMP (cp) <item> riferimento al compilatore ottimizzatore KAI (<bf>Gero Wedemann</bf>) <item> esistono schede madri quad-celeron (<bf>Jeffrey H. Ingber</bf>) </itemize> <tag/v1.6, 21 ottobre 1999 <itemize> <item> aggiunte informazioni sulla perturbazione della schedulazione in xosview <item> aggiunta informazione sul messaggio "APIC error interrupt on CPU#n" <item> aggiunta informazione sul blocco hard <item> eliminatab la sezione "Come ottenere le massime prestazioni" (era obsoleta) <item> aggiunte informazioni su sistemi dual con differenti processori x86 (un Celeron e un P-II) </itemize> <tag/v1.5, 4 ottobre 1999 <itemize> <item> maggiori precisazioni nella descrizione di PSET </itemize> <tag/v1.4, 30 settembre 1999 <itemize> <item> precisato il supporto a MTRR per un kernel SMP su x86 (me) </itemize> <tag/v1.3, 29 settembre 1999 <itemize> <item> molte e molte correzioni di grammatica e tipografiche (<bf>Wade Hampton</bf> aka hww) <item> aggiunte informazioni nella breve introduzione relativa alle diferenze tra 2.2/2.4/2.0 (hww) <item> aggiunte passo dopo passo cose da fare per ricompilare un kernel (hww e me) <item> aggiunte informazioni relative a problemi sui moduli SMP/UP (hww) <item> aggiunte precisazioni nella sezione Posix Threads relative all'utente (hww) vs. i thread del kernel (hww) <item> nuovo paragrafo circa NFS e i lock del kernel (hww) <item> nuovo paragrafo circa i lock del kernel senza messaggi (hww) <item> nuovo paragrafo circa il debug dei problemi dei blocchi (hww) <item> aggiunte informazioni circa i problemi del surriscaldamento (hww) <item> aggiornamenti misti dimenticati (hww) <item> nuovo paragrafo circa l'accesso al floppy e all'audio (hww) </itemize> <tag/v1.2, 27 settembre 1999 <itemize> <item> modifica del nome: questo documento adesso è un HOWTO. TWD, e veloce! (<bf>Guylhem Aznar</bf>) </itemize> <tag/v1.1, 26 settembre 1999 <itemize> <item> aggiunto un link alla prima bozza delle FAQ di Chris Pirih <item> ampliate le problematiche relative agli IRQ </itemize> <tag/v1.00, 25 settembre 1999 <itemize> <item> primo aggiornamento dopo tanto tanto tempo! <item> riviste interamente le FAQ: è uscito il 2.2 e è prossimo il 2.4 <item> aggiunte informazioni sui lock del kernel da Ingo Molnar <item> eliminato paragrafo "Che prestazioni avranno le mie applicazioni sotto SMP ?": obsoleto <item> eliminato paragrafo "Il mio sistema SMP si blocca tutte le volte.":obsoleto <item> eliminato paragrafo "State eseguendo il 2.0.35 non siete voi ?": obsoleto <item> eliminato paragrafo "E' risaputo che alcuni hardware causano problemi.":obsoleto <item> ripulita la sezione "Schede madri con problemi conosciuti". Si dovrebbe ri-iniziarla da zero <item> eliminata la sezione "Schede madri senza problemi conosciuti": obsoleta <item> aggiornata la sezione dual celeron (numerose persone) <item> aggiunta "macchine SPARC sun4m SMP" alle macchine sparc SMP supportate (<bf>Anton Blanchard</bf>) <item> aggiunto un paragrafo "Durante l'avvio della macchina le segnalazioni si stoppano su un problema IOAPIC" nella sezione "Perchè non funziona la mia macchina ?" <item> aggiunto un paragrafo "E le prestazioni dell'SMP ?" <item> aggiornato paragrafo "Perchè il mio vecchio Compaq non funziona ?" <item> corretto un link obsoleto <item> aggiunto in link alle patch Ingo test SMP </itemize> <tag/v0.54, 13 marzo 1999 <itemize> <item> Aggiunta una sezione circa i sistemi SMP Alpha </itemize> <tag/v0.53, 08 marzo 1999 <itemize> <item> Aggiunta una sezione circa i sistemi SMP PowerPC </itemize> <tag/v0.52, 07 marzo 1999 <itemize> <item> Aggiunta una sezione circa i sistemi SMP Sparc </itemize> <tag/v0.51, 06 marzo 1999 <itemize> <item> Aggiunta una sezione dual-celeron <item> Eliminata la sezione Adaptec <item> Aggiornato link a procps <item> Aggiornato link a xosview <item> Aggiunta una risposta per l'hang di avvio del quad Xeon <item> Aggiornato paragrafo circa la patch a glibc per gd: dovrebbe esere inclusa in RH 5.2 </itemize> <tag/v0.50, 03 febraio 1999 <itemize> <item> Aggiornato link a "Programmi Multithread su linux" </itemize> <tag/v0.49, 13 gennaio 1999 <itemize> <item> Aggiornato CONFIG_SMP. Aggiunto .txt alla Documentazione/smp. (<bf>Michael Elizabeth Chastain</bf>) </itemize> <tag/v0.48, 10 dicembre 1998 <itemize> <item> Corretti errori di ortografia. Corretto indirizzo Email. </itemize> <tag/v0.47, 20 novembre 1998 <itemize> <item> Aggiunto 2.0.36 come patch a MTRR (relativo al problema BogoMips) </itemize> <tag/v0.46, 10 novembre 1998 <itemize> <item> Aggiornamento circa le schede madri Epox KP6-LS </itemize> <tag/v0.45, 25 ottobre 1998 <itemize> <item> Corretto un errore riguardante il file /proc/stat <item> Aggiunto un link al sito CESDIS Ethernet Linux Drivers </itemize> <tag/v0.44, 14 ottobre 1998 <itemize> <item> Aggiornato il link alla pagina web: Schede madri risapute che eseguono Linux SMP <item> Aggiunta la spiegazione di Jakob su come sincronizzare sistemi SMP con kernel 2.0 </itemize> <tag/v0.43, 9 settembre 1998 <itemize> <item> Aggiornata la prima domanda nella sezione 3.1 <item> Aggiornato link mt-Mesa: multi-thread è incluso come sperimentale nella distribuzione Mesa </itemize> <tag/v0.42, 2 settembre 1998/ <itemize> <item> Lievi aggiornamenti estetici nella sezione 3.3 <item> Due link (multithread Mesa e prestazioni SMP) sono indicati obsoleti <item> Aggiornato il paragrafo circa i thread e le eccezioni in C++ (sezione 3.3) </itemize> <tag/v0.41, 1 settembre 1998/ <itemize> <item> Aggiunta una sezione major: "3.3 Programmazione SMP" scritta da Jakob Østergaard <item> spostati alcuni paragrafi dalla sezione "3.2 Lato utente" alla sezione 3.3 </itemize> <tag/v0.40, 27 agosto 1998/ <itemize> <item> Aggiornata la sezione 3.1, paragrafo 7: affinità di processore </itemize> <tag/v0.39, 27 agosto 1998/ <itemize> <item> Aggiornamenti necessari alla versione BIOS Award per le schede madri Tyan (<bf>hASCII</bf>) <item> Aggiunto un paragrafo sugli IRQ nella sezione crash (io e <bf>hASCII</bf>) <item> Aggiunto un buon supporto per Asus P2B-DS (<bf>Ulf Rompe</bf>) <item> Aggiunto un'altro archivio smp-list nella sezione link (<bf>Hank Leininger</bf>) </itemize> <tag/v0.38, 8 agosto 1998/ <itemize> <item> Aggiunto un link alle FAQ Linux Threads </itemize> <tag/v0.37, 30 luglio 1998/ <itemize> <item> <bf>Emil Briggs</bf> stà lavorando sui plugin paralleli per Gimp (vedere "Esistono programi o librerie per thread ?", sezione. "Lato utente") </itemize> <tag/v0.36, 26 luglio 1998/ <itemize> <item> Grazie a <bf>Jakob Østergaard</bf>, due modifiche in "Possibili cause di Crash" <itemize> <item> Modoficato 2.0.33 con 2.0.35 (ultima stabile) <item> Aggiunto un paragrafo "BIOS cause relative al malfunzionamento" </itemize> </itemize> <tag/v0.35, 14 luglio 1998/ <itemize> <item> Aggiunta la scheda N440BX Server tra le schede madri senza problemi <item> Aggiunto un caso di successo per la scheda madre GigaByte con l'aggiornamento del BIOS <item> Aggiunta sezione "Come ottenere massime prestazioni ?" (in attesa di propri contributi ;) </itemize> <tag/v0.34, 10 giugno 1998/ <itemize> <item> Aggiunta una sezione "Compilatore Parallelizzatore/Ottimizzatore per macchine 586/686" nella sezione "Link utili", grazie a <bf>Sumit Roy</bf> <item> Corretto un errore, "Asus P/I-UP5" è di fatto "Asus P/I-P65UP5" </itemize> <tag/v0.33, 3 giugno 1998/ <itemize> <item> Ancora un'altro caso di successo per una scheda madre GigaByte DLX. <item> Un suggerimento per le schede madri Tyan, disabilitare l'opzione del BIOS "DRAM Fast Leadoff" </itemize> <tag/v0.32, 27 maggio 1998/ <itemize> <item> Asus P/I-UP5 aggiunta nella sezione delle schede madri senza problemi </itemize> <tag/v0.31, 18 maggio 1998/ <itemize> <item> Elitegroup P6LX2-A funziona con 2.1.100 e 101 <item> I Bug dovrebbero essere riportati a <tt>linux-smp@vger.rutgers.edu</> </itemize> <tag/v0.30, 12 maggio 1998/ <itemize> <item> SuperMicro adesso è nella sezione delle schede madri senza problemi </itemize> <tag/v0.29, 11 maggio 1998/ <itemize> <item> Un caso di successo per la scheda madre GigaByte 686 con 2.1.101 <item> Aggiunto un nuovo paragrafo nella sezione "Lato utente": "Esistono programmi o librerie per thread ?" <item> La libreria OpenGL Mesa è stata resa multithread. Bene! Vedere la nuova sezione per i dettagli. </itemize> <tag/v0.28, 09 maggio 1998/ <itemize> <item> E disponibile un mirror US di questa FAQ (vedere l'Introduzione) <item> Riunite le due entrate confusionarie Gigabyte 686 </itemize> <tag/v0.27, 05 maggio 1998/ <itemize> <item> Nuove informazioni per i driver per Adaptec e TekRam <item> Le schede madri Micronics W6-LI funzionano sotto SMP </itemize> </descrip> <sect>Lista dei partecipanti Molte grazie a quelli che mi hanno aiutato a manutenere questo HOWTO: <enum> <item> Tigran A. Aivazian <item> John Aldrich <item> Niels Ammerlaan <item> H. Peter Anvin <item> Osamu Aoki <item> Guylhem Aznar <item> Ralf Bächle <item> James Beard <item> Troy Benjegerdes <item> Anton Blanchard <item> Emil Briggs <item> Robert G. Brown <item> Ray Bryant <item> Alexandre Charbey <item> Michael Elizabeth Chastain <item> Samuel S. Chessman <item> Alan Cox <item> Andrew Crane <item> Cort Dougan <item> Patrick Doyle <item> Mark Duguid <item> Stéphane Écolivet <item> Johan Ekenberg <item> Jocelyne Erhel <item> Jay A Estabrook <item> Byron Faber <item> Mark Garlanger <item> hASCII <item> Wade Hampton <item> Andre Hedrick <item> Claus-Justus Heine <item> Benedikt Heinen <item> Florian Hinzmann <item> Moni Hollmann <item> Robert M. Hyatt <item> Jeffrey H. Ingber <item> Richard Jelinek <item> Tony Kocurko <item> Geerten Kuiper <item> Martijn Kruithof <item> Doug Ledford <item> Kumsup Lee <item> Hank Leininger <item> Ryan McCue <item> Paul Mackerras <item> Cameron MacKinnon <item> Joel Marchand <item> David Maslen <item> Chris Mauritz <item> Jean-Francois Micouleau <item> David Miller <item> Ingo Molnar <item> Ulf Nielsen <item> Jakob Oestergaard <item> C Polisher <item> Adrian Portelli <item> Matt Ranney <item> Daniel Roesen <item> Ulf Rompe <item> Jean-Michel Rouet <item> Volker Reichelt <item> Sean Reifschneider <item> Rik van Riel <item> Sumit Roy <item> Thomas Schenk <item> Matthias Schniedermeyer <item> Terry Shull <item> Chris K. Skinner <item> Hans - Erik Skyttberg <item> Szakacsits Szabolcs <item> Jukka Tainio <item> Stig Telfer <item> Simen Timian Thoresen <item> El Warren <item> Gregory R. Warnes <item> Gero Wedemann <item> Christopher Allen Wing <item> Leonard N. Zubkoff <item> Mark Hahn <item> David Haring <item> David Mentre <item> Earle Nietzel <item> Rick Lindsley <item> Vladimir G. Ivanovic <item> Daniel Freedman <item> Matti Aarnio <item> Maciej W. Rozycki </enum> </article>