Differences between version 7 and predecessor to the previous major change of SymmetricMultiProcessing.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 7 | Last edited on Tuesday, November 2, 2004 4:53:14 am | by AristotlePagaltzis | Revert |
| Older page: | version 4 | Last edited on Thursday, April 15, 2004 10:38:38 pm | by StuartYeates | Revert |
@@ -1,9 +1,9 @@
-A system with multiple identical (or at least similar)
[CPU]s having equal access to memory and to the [IO
] subsytem(s). Contrast [NUMA] and AsymmetricMultiProcessing.
+A system with multiple identical [CPU]s having equal access to memory and to the [I/O
] subsytem(s). Contrast [NUMA] and AsymmetricMultiProcessing.
It is an accepted rule of thumb that due to the InterProcessCommunication "friction" required to synchronize tasks across [CPU]s, each additional [CPU] contributes about 1/6 less performance than the previous one. As a result, fitting more than four [CPU]s in a machine tends to cost heaps of money with surprisingly little to show for it.
-On the OperatingSystem level, there is a wide span for the degree of symmetry expressed. On a fully symmetric system, any [CPU] may run any userland process, any kernel process, and any interrupt handler. This is rare in practice due to limitations in various platforms -- most of the time, the interrupt handler can only be run by the first [CPU]. In simpler [
OperatingSystem]
s, this is also the only [CPU] that may kernel tasks. In yet simpler system designs, even user processes are assigned to a fixed [CPU] and cannot move among [CPU]s.
+On the OperatingSystem level, there is a wide span for the degree of symmetry expressed. On a fully symmetric system, any [CPU] may run any userland process, any kernel process, and any interrupt handler. This is rare in practice due to limitations in various platforms -- most of the time, the interrupt handler can only be run by the first [CPU]. In simpler OperatingSystem~
s, this is also the only [CPU] that may kernel tasks. In yet simpler system designs, even user processes are assigned to a fixed [CPU] and cannot move among [CPU]s.
In practice, a less symmetric system OperatingSystem design may not be a drawback. It is desirable to tie processes to a certain [CPU] as long the system load is evenly distributed among [CPU]s, because this maximizes the efficiency of [CPU] caches. Even in a completely symmetric system, an intelligently written scheduler will take this into account and try not to shuffle tasks around needlessly.
-Few normal applications
explicitly exploit SymmetricMultiProcessing,
[Java
] programs being
the exception here
, with their innate multithreadedness
which means things like
the [GUI] and
GarbageCollection run on sepreate CPUs from
the application logic
.
+Applications have to be
explicitly designed to
exploit the additional processing power available in an
[SMP
] system. This is not often
the case. It only commonly applies to multithreaded applications
, which are common in the [Java] world where
the [GUI],
GarbageCollection, and application logic will often
run on sepreate [CPU]s. (What else can you do when all your [I/O] is blocking? At least there are nonblocking [I/O] classes in more recent [Java] versions, but of course they add yet another layer to
the already byzantine library
.)
