mirror of https://github.com/tLDP/LDP
updated
This commit is contained in:
gferg
parent
b87ccdd2cd
commit
6e931958f3
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
<title>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
|
||||
|
|
|
|||
Loading…
Reference in New Issue