Differences between current version and previous revision of SymmetricMultiProcessing.
Other diffs: Previous Major 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 | |
| Older page: | version 6 | Last edited on Sunday, April 18, 2004 2:46:27 am | by StuartYeates | Revert |
@@ -1,13 +1,9 @@
-A system with multiple identical [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.
-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[1]
where the [GUI], GarbageCollection, and application logic will often run on sepreate [CPU]s.
-
-----
-
-[1]
What else can you do when all your [IO
] is blocking? At least there's
nonblocking [IO
] in more recent versions, but of course the new classes
add yet another layer to the already byzantine library.
+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.)
