From 6e931958f3dff45f52c13f21a72216b5c0c9d316 Mon Sep 17 00:00:00 2001 From: gferg <> Date: Thu, 5 Oct 2000 13:43:45 +0000 Subject: [PATCH] updated --- LDP/howto/linuxdoc/SMP-HOWTO.sgml | 178 ++++++++++++++++++++++++------ 1 file changed, 143 insertions(+), 35 deletions(-) diff --git a/LDP/howto/linuxdoc/SMP-HOWTO.sgml b/LDP/howto/linuxdoc/SMP-HOWTO.sgml index 4e7fc638..2feafeea 100644 --- a/LDP/howto/linuxdoc/SMP-HOWTO.sgml +++ b/LDP/howto/linuxdoc/SMP-HOWTO.sgml @@ -4,7 +4,7 @@ Linux SMP HOWTO <author>David Mentré, <tt/David.Mentre@irisa.fr/ -<date>v1.9.1, 28 September 2000 +<date>v1.10, 5 october 2000 <abstract> This HOWTO reviews main issues (and I hope solutions) related to SMP @@ -108,13 +108,13 @@ Chastain</bf>). AND -enable real time clock support by configuring the "RTC support" item -(from <bf>Robert G. Brown</bf>). Note that inserting RTC support -actually doesn't afaik prevent the known problem with SMP clock drift, -but enabling this feature prevents lockup when the clock is read at boot -time. A note from <bf>Richard Jelinek</bf> says also that activating the -Enhanced RTC is necessary to get the second CPU working (identified) on -some original Intel Mainboards. +enable real time clock support by configuring the "RTC support" item (in +"Character Devices" menu) (from <bf>Robert G. Brown</bf>). Note that +inserting RTC support actually doesn't afaik prevent the known problem +with SMP clock drift, but enabling this feature prevents lockup when the +clock is read at boot time. A note from <bf>Richard Jelinek</bf> says +also that activating the Enhanced RTC is necessary to get the second CPU +working (identified) on some original Intel Mainboards. AND @@ -253,7 +253,7 @@ include: <item> <bf>Where should one report SMP bugs to?</bf> <p> -Please report bugs to <tt>linux-smp@vger.rutgers.edu</>. +Please report bugs to <tt>linux-smp@vger.kernel.org</>. <item> <bf>What about SMP performance?</bf> <p> @@ -320,10 +320,6 @@ name="http://lore.ece.utexas.edu/~bgrayson/xosview.html"> You'll find a version patched for 2.2.x kernels by <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"> - -The various Forissier's kernel patches are at: <htmlurl -url="http://www-isia.cma.fr/~forissie/smp_kernel_patch/" -name="http://www-isia.cma.fr/~forissie/smp_kernel_patch/"> </descrip> <p> By the way, you can't monitor processor scheduling precisely with xosview, @@ -582,14 +578,14 @@ recommandation. (<bf>Daniel Roesen</bf>) <item> <bf>Why doesnt my ALR work?</bf> <p> -From <bf>Robert Hyatt</bf> : ALR Revolution quad-6 seems quite safe, +>From <bf>Robert Hyatt</bf> : ALR Revolution quad-6 seems quite safe, while some older revolution quad machines without P6 processors seem "iffy"... <item> <bf>Why does SMP go so slowly?</bf> or <bf>Why does one CPU show a very low bogomips value while the first one is normal?</bf> <p> -From <bf>Alan Cox</bf>: If one of your CPU's is reporting a very low +>From <bf>Alan Cox</bf>: If one of your CPU's is reporting a very low bogomips value the cache is not enabled on it. Your vendor probably provides a buggy BIOS. Get the patch to work around this or better yet send it back and buy a board from a competent supplier. @@ -618,7 +614,7 @@ Nope (according to Alan <tt/:)/ ), 1.4 is just a stricker specs of 1.1. This is known problem with IRQ handling and long kernel locks in the 2.0 series kernels. Consider upgrading to a later 2.2 kernel. <p> -From <bf>Jakob Oestergaard</bf>: Or, consider running xntpd. That should +>From <bf>Jakob Oestergaard</bf>: Or, consider running xntpd. That should keep your clock right on time. (I think that I've heard that enabling RTC in the kernel also fixes the clock drift. It works for me! but I'm not sure whether that's general or I'm just being lucky) @@ -741,7 +737,7 @@ specific. <item> <bf>Cooling problems</bf> <p> -From <bf>Ralf Bächle</bf>: [Related to case size and fans] +>From <bf>Ralf Bächle</bf>: [Related to case size and fans] It's important that the air is flowing. It of course can't where cables etc. are preventing this like in too small cases. On the other side I've seen oversized cases causing big problems. There are some tower @@ -760,8 +756,7 @@ a problem. (<bf>Wade Hampton</bf>) Don't buy cheap RAM and don't use mixed RAM modules on a motherboard that is picky about it. <p> -Especially Tyan motherboards are known to be picky about RAM speed (see -the Tyan paragraph below for a possible solution). +Especially Tyan motherboards are known to be picky about RAM speed. <p> There have been some report of 10ns PC100 RAM being sold with @@ -776,7 +771,7 @@ Check <tt>/proc/cpuinfo</> to see that your CPUs are same stepping. <p> ...and even if it is stable, DON'T overclock. <p> -From <bf>Ralf Bächle</bf>: Overclocking causes very subtle +>From <bf>Ralf Bächle</bf>: Overclocking causes very subtle problems. I have a nice example, one of my overclocked old machines misscomputes a couple of pixels of a 640 x 400 fractal. The problem is only visible when comparing them using tools. So better say <em>never, @@ -816,7 +811,7 @@ url="http://nemo.physics.ncsu.edu/~briggs/vfix.html"> <item> <bf>DONT run emm386.exe before booting linux SMP</bf> <p> -From <bf>Mark Duguid</bf>, dumb rule #1 with W6LI +>From <bf>Mark Duguid</bf>, dumb rule #1 with W6LI motherboards. <tt>;)</> <item> <bf>If the machine reboots/freezes after a while, there can be two good @@ -1050,12 +1045,12 @@ url="http://www.uk.linux.org/SMP/title.html"> <item> linux-smp mailing list <p> To <bf>subscribe</bf>, send <tt/subscribe linux-smp/ in the message body -at <htmlurl url="mailto:majordomo@vger.rutgers.edu" -name="majordomo@vger.rutgers.edu"> +at <htmlurl url="mailto:majordomo@vger.kernel.org" +name="majordomo@vger.kernel.org"> <p> To <bf>unsubscribe</bf>, send <tt/unsubscribe linux-smp/ in the message body at -<htmlurl url="mailto:majordomo@vger.rutgers.edu" -name="majordomo@vger.rutgers.edu"> +<htmlurl url="mailto:majordomo@vger.kernel.org" +name="majordomo@vger.kernel.org"> <p> <url name="Linux SMP archives" url="http://www.linuxhq.com/lnxlists/linux-smp/"> <p> @@ -1123,21 +1118,15 @@ url="http://nemo.physics.ncsu.edu/~briggs/gimp/index.html"> <p> <itemize> -<item> <url name="Forissier kernel patches" -url="http://www-isia.cma.fr/~forissie/smp_kernel_patch/"> - <item> <url name="Patch for a bug in the 440FX chipset" url="http://nemo.physics.ncsu.edu/~briggs/vfix.html"> -<item> <url name="MTRR patch (latest version: 1.9)" -url="http://www.atnf.csiro.au/~rgooch/kernel-patches.html"> - <item> <url name="PSET - Processor Sets for the Linux kernel" url="http://isunix.it.ilstu.edu/~thockin/pset/"> <item> <url name="Ingo Molnar SMP patches" url="http://www.redhat.com/~mingo/"> (for experts only, please read -linux-smp@vger.rutgers.edu) +linux-smp@vger.kernel.org) </itemize> @@ -1177,12 +1166,15 @@ compilers for WinNT <sect>Glossary +<sect1>Definitions <p> <itemize> -<item> <bf>SMP</bf> Symmetric Multi-Processors +<item> <bf>SMP</bf> Symmetric Multi-Processors. -<item> <bf>APIC</bf> Advanced Programmable Interrupt Controler +<item> <bf>UP</bf> Uni-Processor: system with one processor. + +<item> <bf>APIC</bf> Advanced Programmable Interrupt Controler. <item> <bf>thread</bf> A thread is a processor activity in a process. The same process can have multiple threads. Those threads share @@ -1191,14 +1183,126 @@ the process address space and can therefore share data. <item> <bf>pthread</bf> Posix thread, threads defined by the Posix standard. -<item> <bf>APM</bf> Advanced Power Managment +<item> <bf>process</bf> Program in execution, with its environment. + +<item> <bf>MTRR</bf> Memory Type Range Register + +<item> <bf>APM</bf> Advanced Power Management. + +<item> <bf>FPU</bf> Floating Point Unit. Also called arithmetic +co-processor. + +<item> <bf>IRQ</bf> Interrupt ReQuest. + +<item> <bf>EBDA</bf> ?? + +<item> <bf>oops</bf> Internal kernel error. + +<item> <bf>Cluster</bf> Group of computers that achieve a common +computation (also known as Beowulf within the Linux community). + + + </itemize> +<sect1>Concepts +<P> +<itemize> + <item> <bf>Data Races</bf> +<p> +A data race happens when to processes want to modify a shared variable +concurrently without protecting themselves from the effect of the other +process. +<p> +Let A a shared variable. Let P1 and P2 two processes that access this +variable. Those two processes are making the same following operation: +"read A in tmp variable (local to the precess); do tmp = tmp + 1 ; write +tmp in A". If the A variable is not protected by a lock, resulting +executions could not correspond to what is espected. For example, here +is two examples if one do not lock A: +<verb> +case #1: +A=0 +P1: read A -> tmp1 (so tmp1 is 0) +P2: read A -> tmp2 (so tmp2 is 0) +P1: tmp1 = tmp1 + 1 (so tmp1 is 1) +P2: tmp2 = tmp2 + 1 (so tmp2 is 1) +P1: tmp1 -> write A (so A is 1) +P2: tmp2 -> write A (so A is 1) +</verb> +<p> +<verb> +case #2: +A=0 +P1: read A -> tmp1 (so tmp1 is 0) +P1: tmp1 = tmp1 + 1 (so tmp1 is 1) +P1: tmp1 -> write A (so A is 1) +P2: read A -> tmp2 (so tmp2 is 1) +P2: tmp2 = tmp2 + 1 (so tmp2 is 2) +P2: tmp2 -> write A (so A is 2) +</verb> +<p> +To avoid this kind of problem, one uses a lock: +<verb> +A=0: +P1: lock A +P1: read A -> tmp1 (so tmp1 is 0) +P2: lock A (so P2 is blocked) +P1: tmp1 = tmp1 + 1 (so tmp1 is 1) +P1: tmp1 -> write A (so A is 1) +P1: unlock A (so P2 is unblocked) +P2: read A -> tmp2 (so tmp2 is 1) +P2: tmp2 = tmp2 + 1 (so tmp2 is 2) +P2: tmp2 -> write A (so A is 2) +P2: unlock A +</verb> + + <item> <bf>Deadlock</bf> +<p> +This is an inter-blocking that occurs when two processes want to access +at shared variables mutually locked. For example, let A and B two locks +and P1 and P2 two processes: +<p> +<verb> +P1: lock A +P2: lock B +P1: lock B (so P1 is blocked by P2) +P2: lock A (so P2 is blocked by P1) +</verb> +Process P1 is blocked because it is waiting for the unlocking of B +variable by P2. However P2 also needs the A variable to finish its +computation and free B. So we have a deadlock. +<p> +In this example, the problem is very simple. But imagine what can happen +in a 2 millions of lines of code (like the linux kernel) with hundreds +of locks. :-) +</itemize> + + <sect> What's new ? <p> <descrip> +<tag/v1.10, 5 october 2000 +<itemize> +<item> New linux-smp mailing-list adress : linux-smp@vger.kernel.org +(me) +<item> Tell where to find RTC setting in kernel config (<bf>Patrick +Doyle</bf>) +<item> glossary updated and concepts added (from a french version made +by <bf>Ludovic Danigo</bf>) +<item> Fixed an inconsistency (<bf>Matthias Schniedermeyer</bf>) +<item> Deleted wrong links (<bf>Johan Ekenberg</bf>) +</itemize> + +<tag/v1.9.1, 28 September 2000 +<itemize> +<item> updated with a submission from <bf>Stig Telfer</bf> detailing SMP support +on API Alpha systems +</itemize> + + <tag/v1.9, 13 january 2000 <itemize> <item> Remember to disable all BIOS power-save features (<bf>Osamu @@ -1506,8 +1610,10 @@ Many thanks to those who help me to maintain this HOWTO: <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 @@ -1549,11 +1655,13 @@ Many thanks to those who help me to maintain this HOWTO: <item> Sean Reifschneider <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