[rescue] OS X and dual CPU machines?
Curtis H. Wilbar Jr.
rescue at hawkmountain.net
Mon Jun 9 11:04:19 CDT 2003
>Subject: Re: [rescue] OS X and dual CPU machines?
>From: "r.stricklin" <bear at typewritten.org>
>On Monday, June 9, 2003, at 12:38 AM, Curtis H. Wilbar Jr. wrote:
>>> Single thread: 4.23 seconds.
>>> Two threads: 18.915 seconds.
>>> Clearly something suboptimal is happening.
>> what could be happening is that there is one lock around one (or both
>> of those devices).... how a MP machine behaves with this test is
>> irrelevant to real world usage.
>I agree completely that it's fairly irrelevant to real-world usage.
>But I would argue that it taking consistently four times as long to run
>two fhlushstones in parallel than it does to run one would tend to
>indicate something peculiar going on. IRIX 6.5 had a similar problem
>with IP19 when you got to more than two CPUs and three fhlushstones.
>Suddenly it would hit a wall and things started taking three or four
>times longer to run. They fixed it around 6.5.12 (read the release
Could be that only one proc can be accessing each of the devices at
once.... could cause a continuous context switching for every block
tranferred (process context switching has an overhead).... what
would be interesting is varying the block sizes....
Also of interest would be how long it takes to run two of them with
only one processor enabled (or if the arch doesn't support disabling of
a processor, run it uniprocessor)....
While the worst case idea would be to see it take twice as long or a fraction
more (for overhead), this doesn't necessarily indicate anything wrong,
something that needs fixing, or any indication of real world effects.
Definatly interseting, and curious.... have you ever tried trussing/tracing
the syscalls in each running process to see what might be happening... it
may give some insight...
>You'll find that even on SunOS 4.1.4 two parallel fhlushstones run in
>1.7x a single fhlushstone. This was on a 4x RT605 4/670, not exactly
Considering SunOS 4.X has one kernel lock, I would have expected 2X or
a tad more... however maybe the time is saved as a nother process has
the process all ready to go and it is just waiting on a spin lock for
the kernel.... there is some trickery with overhead somewhere.... with
only one kernel lock, only one process can access devices at one time...
>Also, I apologize for using the term 'threading' in a haphazard manner
>in my last message.
>rescue list - http://www.sunhelp.org/mailman/listinfo/rescue
Hawk Mountain Networks
rescue at hawkmountain.net
My e-mail is protected against viruses and spam by MailGuardian
Top notch protection at unbelievable prices
More information about the rescue