>For some systems, 2.3
>would work fine. On any desktop slower than a SS10, it's likely to
>feel painfully slow, particularly in less than 24 MB of memory. On a
>lightly or moderately loaded SS10 or above, with enough memory, 2.3
>should be fine.
That's not been our experience. We found our IPCs felt as spritely or more so
running Solaris 2.3 than they did running SunOS 4.1.1 (both running X11R5),
depending on what was being done. However, the Solaris 2.x kernel seems to
gobble up about 4MB of memory more than the 4.x kernel.
Note: spriteliness of feel in Solaris 2.x depends on how you tune your
scheduler. The default tuning in 2.3 is fairly reasonable, except that it
breaks nice. We rolled our own. Note: the 4.x scheduler isn't tunable.
Certain applications (eg. ld) seem to require more memory in Solaris
2.3 than they did under 4.x. Since software developers seem to run things
like ld quite a bit (which is no surprise), more memory for them seems
A good rule of thumb: start with the amount of memory you needed for 4.x,
add 4MB, and add another 4MB if the machine is being heavily used by software
Quote:>The primary problem with multiple processors under 2.3 is that select
>and poll are not fully symmetrized in 2.3 and earlier. This is
>supposedly fixed in 2.4. The effect is that telnet and similar
>network code can't effectively make use of multiple processors in
>versions older than 2.4. Of course 4.1.3 isn't symmetrized at all.
>To a first approximation, you're going to lose under 4.1.3 with N
>processors if you're got more than 1/N% system time (as shown, e.g. in
>vmstat). In practice normal timesharing seems to work fine with 2
>processors under 4.1.3. Compute-bound stuff works even with 4
>processors. There have been a number of reports of trouble with
>general timesharing loads on 4 processors. Typical timesharing loads
>have a bit more than 50% system time. So with more than 2 processors,
>you have big trouble under 4.1.3. Other than that, 4.1.3 works fine
>for us with multiple processors. (The only problems we seen with our
>MP systems under 4.1.3 are the standard problems with 51 processors.
>But we see that with single processor systems too, and we think the
>fix works just as well for MP sysems as SP systems.)
There are a few issues that are all mixed together here that need to be
distinguished. Firstly, there's the question of how the multiprocessing
implementations of Solaris 2.x and SunOS 4.1.x compare. Secondly, there's
the question of multiprocessing support for SuperSPARC under SunOS 4.1.x.
Finally, there's the question of how individual applications can take
advantage of multiprocessing.
Addressing the first question, Sun added multiprocessing support to 4.1.2
(and later) so that they could ship the 600 series (with two or four Ross 601
processors) with an OS that worked (Solaris 2.x was far from being stable at
the time). Rather than multithread the 4.x kernel (a difficult and
time-consuming task), they simply set up a kernel mutex to ensure that only one
processor can run kernel code at a time (note: all processors are treated
equally, so this actually is, contrary to popular rumour, a form of symmetric
multiprocessing). This was relatively simple to implement, and offers
reasonably good performance in some circumstances, but deteriorates when many
processes want to delve into the kernel at once. (Think four *agers, one
bathroom.) In practice, 4.x multiprocessing works well for single-user
machines with long-running compute-bound background tasks, and fairly
decently for large timesharing machines with two processors. Adding another
two processors to a large timesharing machine provides some improvement, but
not as much as would be expected. This is what Charles is discussing in the
middle of the above paragraph.
Solaris 2.x, on the other hand, has a multithreaded kernel, which permits
several processors to run kernel code at once. For timesharing workloads, it
tends to get quite a bit more out of four processors than 4.x does.
As for the second question, Sun does not officially support multiprocessing
using SuperSPARC processors in SunOS 4.1.x. However, the multiprocessing
code is pretty much independent in the kernel from the processor-specific
code, and if you try multiple SuperSPARCs in a SS10, SS20, or 600 series
machine, it will more-or-less work. However, Sun management (for non-technical
reasons) decided not to test and verify multiple SuperSPARCs under 4.1.x.
This means that it may well be buggy (it's difficult to get MP cache coherency
right, and the SuperSPARC caches are quite different from the cache used by
the Ross 601), and those who do this do so at their own risk. Some people have
chosen to take the risk, and run their systems this way. We don't, ourselves.
Finally, the third question: individual applications can take advantage of
multiprocessing under 4.x only by making use of several processes (using fork
and exec), which are assigned to different processors automatically by the
kernel. This scheme works for Solaris 2.x too, but 2.x also offers a
user-level threads library which can be used to multithread a single process.
However, for a library call to be effectively used by a multithreaded
process, it must be re-entrant (i.e. if one thread makes a library call
before another has finished making the same call, things must work properly).
In 2.3, the socket library (where the "select" call may be found) is not
re-entrant, I believe, which is what Charles is referring to at the beginning
of his paragraph.
University of Toronto EA201B,(416)978-1928