Also -

HPC clusters are commonly dedicated to running parallel jobs with exactly 
one process per CPU.  HPC is about getting computation done and letting a 
CPU time slice among competing processes always has overhead (CPU time not 
spent on the computation).

Unless you are trying to run extra processes that take turns for the 
available processors, there is no gain from freeing up a CPU during a 
blocking call.  It is the difference between spinning in the poll and 
spinning in the OS "idle process".

Dick Treumann  -  MPI Team 
IBM Systems & Technology Group
Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846         Fax (845) 433-8363




From:
Ralph Castain <r...@open-mpi.org>
To:
Open MPI Users <us...@open-mpi.org>
List-Post: users@lists.open-mpi.org
Date:
12/08/2010 10:36 AM
Subject:
Re: [OMPI users] curious behavior during wait for broadcast: 100% cpu
Sent by:
users-boun...@open-mpi.org



I know we have said this many times - OMPI made a design decision to poll 
hard while waiting for messages to arrive to minimize latency.

If you want to decrease cpu usage, you can use the yield_when_idle option 
(it will cost you some latency, though) - see ompi_info --param ompi all

Or don't set affinity and we won't be as aggressive - but you'll lose some 
performance

Choice is yours! :-)

On Dec 8, 2010, at 8:08 AM, Hicham Mouline wrote:

> Hello,
> 
> on win32 openmpi 1.4.3, I have a slave process that reaches this 
pseudo-code and then blocks and the CPU usage for that process stays at 
25% all the time (I have a quadcore processor). When I set the affinity to 
1 of the cores, that core is 100% busy because of my slave process.
> 
> main()
> {
> ....
> .....
> MPI_ISEND
> 
> std::cout<< "about to get broadcast"<<std::endl;
> MPI_Bcast of an integer
> std::cout<< " broadcast received"<<std::endl;
> ...
> }
> 
> The first printout is seen but not the next which makes me thing the 
process is inside the MPI_Bcast call. Should the CPU be 100% busy while 
this call is waiting for the broadcast message to arrive?
> 
> Any ideas? below the output of ompi-info:
> 
------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 
>                 Package: Open MPI 
>                          Distribution
>                Open MPI: 1.4.3
>   Open MPI SVN revision: r23834
>   Open MPI release date: Oct 05, 2010
>                Open RTE: 1.4.3
>   Open RTE SVN revision: r23834
>   Open RTE release date: Oct 05, 2010
>                    OPAL: 1.4.3
>       OPAL SVN revision: r23834
>       OPAL release date: Oct 05, 2010
>            Ident string: 1.4.3
>                  Prefix: C:/Program Files/openmpi
> Configured architecture: x86 Windows-5.1
>          Configure host: LC12-003-D-055A
>           Configured by: hicham.mouline
>           Configured on: 18:07 19/11/2010
>          Configure host: 
>                Built by: hicham.mouline
>                Built on: 18:07 19/11/2010
>              Built host: 
>              C bindings: yes
>            C++ bindings: yes
>      Fortran77 bindings: no
>      Fortran90 bindings: no
> Fortran90 bindings size: na
>              C compiler: C:/Program Files/Microsoft Visual Studio
>                          9.0/VC/bin/cl.exe
>     C compiler absolute: C:/Program Files/Microsoft Visual Studio
>                          9.0/VC/bin/cl.exe
>            C++ compiler: C:/Program Files/Microsoft Visual Studio
>                          9.0/VC/bin/cl.exe
>   C++ compiler absolute: C:/Program Files/Microsoft Visual Studio
>                          9.0/VC/bin/cl.exe
>      Fortran77 compiler: CMAKE_Fortran_COMPILER-NOTFOUND
>  Fortran77 compiler abs: none
>      Fortran90 compiler:
>  Fortran90 compiler abs: none
>             C profiling: yes
>           C++ profiling: yes
>     Fortran77 profiling: no
>     Fortran90 profiling: no
>          C++ exceptions: no
>          Thread support: no
>           Sparse Groups: no
>  Internal debug support: no
>     MPI parameter check: runtime
> Memory profiling support: no
> Memory debugging support: no
>         libltdl support: no
>   Heterogeneous support: no
> mpirun default --prefix: yes
>         MPI I/O support: yes
>       MPI_WTIME support: gettimeofday
> Symbol visibility support: yes
>   FT Checkpoint support: yes  (checkpoint thread: no)
>           MCA backtrace: none (MCA v2.0, API v2.0, Component v1.4.3)
>           MCA paffinity: windows (MCA v2.0, API v2.0, Component v1.4.3)
>               MCA carto: auto_detect (MCA v2.0, API v2.0, Component 
v1.4.3)
>           MCA maffinity: first_use (MCA v2.0, API v2.0, Component 
v1.4.3)
>               MCA timer: windows (MCA v2.0, API v2.0, Component v1.4.3)
>         MCA installdirs: windows (MCA v2.0, API v2.0, Component v1.4.3)
>         MCA installdirs: env (MCA v2.0, API v2.0, Component v1.4.3)
>         MCA installdirs: config (MCA v2.0, API v2.0, Component v1.4.3)
>                 MCA crs: none (MCA v2.0, API v2.0, Component v1.4.3)
>                 MCA dpm: orte (MCA v2.0, API v2.0, Component v1.4.3)
>              MCA pubsub: orte (MCA v2.0, API v2.0, Component v1.4.3)
>           MCA allocator: basic (MCA v2.0, API v2.0, Component v1.4.3)
>           MCA allocator: bucket (MCA v2.0, API v2.0, Component v1.4.3)
>                MCA coll: basic (MCA v2.0, API v2.0, Component v1.4.3)
>                MCA coll: hierarch (MCA v2.0, API v2.0, Component v1.4.3)
>                MCA coll: self (MCA v2.0, API v2.0, Component v1.4.3)
>                MCA coll: sm (MCA v2.0, API v2.0, Component v1.4.3)
>                MCA coll: sync (MCA v2.0, API v2.0, Component v1.4.3)
>               MCA mpool: rdma (MCA v2.0, API v2.0, Component v1.4.3)
>               MCA mpool: sm (MCA v2.0, API v2.0, Component v1.4.3)
>                 MCA pml: ob1 (MCA v2.0, API v2.0, Component v1.4.3)
>                 MCA bml: r2 (MCA v2.0, API v2.0, Component v1.4.3)
>                 MCA btl: self (MCA v2.0, API v2.0, Component v1.4.3)
>                 MCA btl: sm (MCA v2.0, API v2.0, Component v1.4.3)
>                 MCA btl: tcp (MCA v2.0, API v2.0, Component v1.4.3)
>                MCA topo: unity (MCA v2.0, API v2.0, Component v1.4.3)
>                 MCA osc: pt2pt (MCA v2.0, API v2.0, Component v1.4.3)
>                 MCA osc: rdma (MCA v2.0, API v2.0, Component v1.4.3)
>                 MCA iof: hnp (MCA v2.0, API v2.0, Component v1.4.3)
>                 MCA iof: orted (MCA v2.0, API v2.0, Component v1.4.3)
>                 MCA iof: tool (MCA v2.0, API v2.0, Component v1.4.3)
>                 MCA oob: tcp (MCA v2.0, API v2.0, Component v1.4.3)
>                MCA odls: process (MCA v2.0, API v2.0, Component v1.4.3)
>               MCA rmaps: round_robin (MCA v2.0, API v2.0, Component 
v1.4.3)
>               MCA rmaps: seq (MCA v2.0, API v2.0, Component v1.4.3)
>                 MCA rml: ftrm (MCA v2.0, API v2.0, Component v1.4.3)
>                 MCA rml: oob (MCA v2.0, API v2.0, Component v1.4.3)
>              MCA routed: binomial (MCA v2.0, API v2.0, Component v1.4.3)
>              MCA routed: linear (MCA v2.0, API v2.0, Component v1.4.3)
>                 MCA plm: process (MCA v2.0, API v2.0, Component v1.4.3)
>              MCA errmgr: default (MCA v2.0, API v2.0, Component v1.4.3)
>                 MCA ess: env (MCA v2.0, API v2.0, Component v1.4.3)
>                 MCA ess: hnp (MCA v2.0, API v2.0, Component v1.4.3)
>                 MCA ess: singleton (MCA v2.0, API v2.0, Component 
v1.4.3)
>                 MCA ess: tool (MCA v2.0, API v2.0, Component v1.4.3)
>             MCA grpcomm: basic (MCA v2.0, API v2.0, Component v1.4.3)
> 
> regards,
> 
> _______________________________________________
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users


_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users


Reply via email to