Does anyone know of a good document or resource describing how Solaris
balances CPU usage on a multiple processor system? I'm trying to
understand why, on one of our 440s running Solaris 10, we typically
see one of the CPUs running at 100% while the other 3 are basically
idle.
|
|
0
|
|
|
|
Reply
|
bonk.brennan (23)
|
4/7/2007 9:34:01 PM |
|
In article <1175981641.058348.324950@d57g2000hsg.googlegroups.com>, Bonk <bonk.brennan@gmail.com> wrote:
> Does anyone know of a good document or resource describing how Solaris
> balances CPU usage on a multiple processor system? I'm trying to
> understand why, on one of our 440s running Solaris 10, we typically
> see one of the CPUs running at 100% while the other 3 are basically
> idle.
I'd guess this may be an app that doesn't support threads?
-Dan
|
|
0
|
|
|
|
Reply
|
Dan
|
4/7/2007 9:39:04 PM
|
|
Bonk wrote:
> Does anyone know of a good document or resource describing how Solaris
> balances CPU usage on a multiple processor system? I'm trying to
> understand why, on one of our 440s running Solaris 10, we typically
> see one of the CPUs running at 100% while the other 3 are basically
> idle.
>
The following program (pseudo code) might account for something like that:
A: GOTO A
Any CPU bound program might have the same effect on CPU usage although
most would accomplish more than my example above.
Two instances of the above program should peg two CPUs!
|
|
0
|
|
|
|
Reply
|
Richard
|
4/7/2007 10:07:41 PM
|
|
Bonk wrote:
> Does anyone know of a good document or resource describing how Solaris
> balances CPU usage on a multiple processor system? I'm trying to
> understand why, on one of our 440s running Solaris 10, we typically
> see one of the CPUs running at 100% while the other 3 are basically
> idle.
>
In order for one process to use more than one CPU at the same time, it
must be written as a multi-threaded application. Most are not written
like this.
And those that are written as multi-threaded, are often not able to make
very good use of multiple CPUs.
In order to make good use of the multiple cpus, you will either have to
1) Have a multi-threaded CPU intensive program that is written in such a
way that it can make good use of the multiple CPUs
OR
2) Have lots of processes all wanting CPU time. Then Solaris will
distribute those processes among the different CPUs.
You can often gain significant reductions in time to compile programs by
using running 'make' in parallel
gmake -j10
will set off 10 parallel compilations, which will make good use of your
4 CPUs.
--
Dave (from the UK)
Please note my email address changes periodically to avoid spam.
It is always of the form: month-year@althorne.org
Hitting reply will work for a few months only - later set it manually.
http://chessdb.sourceforge.net/ - a Free open-source Chess Database
|
|
0
|
|
|
|
Reply
|
Dave
|
4/7/2007 10:19:14 PM
|
|
On Apr 7, 6:19 pm, "Dave (from the UK)" <see-my-signat...@southminster-
branch-line.org.uk> wrote:
> Bonk wrote:
> > Does anyone know of a good document or resource describing how Solaris
> > balances CPU usage on a multiple processor system? I'm trying to
> > understand why, on one of our 440s running Solaris 10, we typically
> > see one of the CPUs running at 100% while the other 3 are basically
> > idle.
>
> In order for one process to use more than one CPU at the same time, it
> must be written as a multi-threaded application. Most are not written
> like this.
>
> And those that are written as multi-threaded, are often not able to make
> very good use of multiple CPUs.
>
> In order to make good use of the multiple cpus, you will either have to
>
> 1) Have a multi-threaded CPU intensive program that is written in such a
> way that it can make good use of the multiple CPUs
>
> OR
>
> 2) Have lots of processes all wanting CPU time. Then Solaris will
> distribute those processes among the different CPUs.
>
> You can often gain significant reductions in time to compile programs by
> using running 'make' in parallel
>
> gmake -j10
>
> will set off 10 parallel compilations, which will make good use of your
> 4 CPUs.
>
> --
> Dave (from the UK)
>
> Please note my email address changes periodically to avoid spam.
> It is always of the form: month-y...@althorne.org
> Hitting reply will work for a few months only - later set it manually.
>
> http://chessdb.sourceforge.net/- a Free open-source Chess Database
I was actually looking for a document from SUN or some other source
that described how all this works in general terms.
|
|
0
|
|
|
|
Reply
|
Bonk
|
4/11/2007 5:45:55 PM
|
|
On Apr 7, 3:19 pm, "Dave (from the UK)" <see-my-signat...@southminster-
branch-line.org.uk> wrote:
> Bonk wrote:
> > Does anyone know of a good document or resource describing how Solaris
> > balances CPU usage on a multiple processor system? I'm trying to
> > understand why, on one of our 440s running Solaris 10, we typically
> > see one of the CPUs running at 100% while the other 3 are basically
> > idle.
> In order for one process to use more than one CPU at the same time, it
> must be written as a multi-threaded application. Most are not written
> like this.
> And those that are written as multi-threaded, are often not able to make
> very good use of multiple CPUs.
> In order to make good use of the multiple cpus, you will either have to
> 1) Have a multi-threaded CPU intensive program that is written in such a
> way that it can make good use of the multiple CPUs
>
> OR
>
> 2) Have lots of processes all wanting CPU time. Then Solaris will
> distribute those processes among the different CPUs.
> You can often gain significant reductions in time to compile programs by
> using running 'make' in parallel
> gmake -j10
> will set off 10 parallel compilations, which will make good use of your 4 CPUs.
Until it falls over. If you really want to see parallel compilation in
action use
Sun Studio dmake instead : >
That actually works every time Ive used it whereas GNU make has
croaked
every time part way through a reasonably complex build. Seems to get
out of sync.
|
|
0
|
|
|
|
Reply
|
gerryt
|
4/11/2007 6:32:55 PM
|
|
|
5 Replies
184 Views
(page loaded in 0.066 seconds)
|