April 2015 - discuss - mailman3.cels.anl.gov

Unexpected results
by Ken Miller 02 Apr '15

02 Apr '15

Hello, I am hoping someone might be able to point out what I am doing wrong. I have setup a Raspberry Pi cluster by going through a couple tutorials. The last step is to use MPI to test the cluster. Everything was going great until I ran the following command: mpiexec -f machinefile -n 4 hostname My machinefile contains the following: pi@Pi01 ~/mpi_test $ cat machinefile 192.168.2.121 192.168.2.122 192.168.2.123 192.168.2.124 But, when I run the mpiexec command, I get the following error: pi@Pi01 ~/mpi_test $ mpiexec -f machinefile -n 4 hostname Pi01 [mpiexec@Pi01] control_cb (/home/pi/mpich2/mpich-3.1/src/pm/hydra/pm/pmiserv/pmiserv_cb.c:200): assert (!closed) failed [mpiexec@Pi01] HYDT_dmxu_poll_wait_for_event (/home/pi/mpich2/mpich-3.1/src/pm/hydra/tools/demux/demux_poll.c:76): callback returned error status [mpiexec@Pi01] HYD_pmci_wait_for_completion (/home/pi/mpich2/mpich-3.1/src/pm/hydra/pm/pmiserv/pmiserv_pmci.c:198): error waiting for event [mpiexec@Pi01] main (/home/pi/mpich2/mpich-3.1/src/pm/hydra/ui/mpich/mpiexec.c:336): process manager error waiting for completion pi@Pi01 ~/mpi_test $ Clearly, I am missing something. Would appreciate any help in advance. Thanks. Ken ps. I am connected to the other Pis evident by the following ping results. I can also log into each of the other 3 Pis. ping 192.168.2.122 PING 192.168.2.122 (192.168.2.122) 56(84) bytes of data. 64 bytes from 192.168.2.122: icmp_req=1 ttl=64 time=0.807 ms 64 bytes from 192.168.2.122: icmp_req=2 ttl=64 time=0.626 ms 64 bytes from 192.168.2.122: icmp_req=3 ttl=64 time=0.614 ms 64 bytes from 192.168.2.122: icmp_req=4 ttl=64 time=0.605 ms 64 bytes from 192.168.2.122: icmp_req=5 ttl=64 time=0.603 ms ^C --- 192.168.2.122 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4002ms rtt min/avg/max/mdev = 0.603/0.651/0.807/0.078 ms pi@Pi01 ~/mpi_test $ ping 192.168.2.123 PING 192.168.2.123 (192.168.2.123) 56(84) bytes of data. 64 bytes from 192.168.2.123: icmp_req=1 ttl=64 time=0.794 ms 64 bytes from 192.168.2.123: icmp_req=2 ttl=64 time=0.634 ms 64 bytes from 192.168.2.123: icmp_req=3 ttl=64 time=0.628 ms 64 bytes from 192.168.2.123: icmp_req=4 ttl=64 time=0.607 ms ^C --- 192.168.2.123 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3003ms rtt min/avg/max/mdev = 0.607/0.665/0.794/0.081 ms pi@Pi01 ~/mpi_test $ ping 192.168.2.124 PING 192.168.2.124 (192.168.2.124) 56(84) bytes of data. 64 bytes from 192.168.2.124: icmp_req=1 ttl=64 time=0.787 ms 64 bytes from 192.168.2.124: icmp_req=2 ttl=64 time=0.632 ms 64 bytes from 192.168.2.124: icmp_req=3 ttl=64 time=0.612 ms ^C --- 192.168.2.124 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 0.612/0.677/0.787/0.078 ms pi@Pi01 ~/mpi_test $ _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] How to use non-blocking send/receive without calling MPI_Wait
by Junchao Zhang 02 Apr '15

02 Apr '15

Does MPI_Test fit your needs? --Junchao Zhang On Thu, Apr 2, 2015 at 7:16 PM, Lei Shi <lshi(a)ku.edu> wrote: > I want to use non-blocking send/rev MPI_Isend/MPI_Irev to do > communication. But in my case, I don't really care what kind of data I get > or it is ready to use or not. So I don't want to waste my time to do any > synchronization by calling MPI_Wait or etc API. > > But when I avoid calling MPI_Wait, my program is freezed several secs > after running some iterations (after multiple MPI_Isend/Irev callings), > then continues. It takes even more time than the case with MPI_Wait. So my > question is how to do a "true" non-blocking communication without waiting > for the data ready or not. Thanks. > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

How to use non-blocking send/receive without calling MPI_Wait
by Lei Shi 02 Apr '15

02 Apr '15

I want to use non-blocking send/rev MPI_Isend/MPI_Irev to do communication. But in my case, I don't really care what kind of data I get or it is ready to use or not. So I don't want to waste my time to do any synchronization by calling MPI_Wait or etc API. But when I avoid calling MPI_Wait, my program is freezed several secs after running some iterations (after multiple MPI_Isend/Irev callings), then continues. It takes even more time than the case with MPI_Wait. So my question is how to do a "true" non-blocking communication without waiting for the data ready or not. Thanks. _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] MPI_DIMS_CREATE
by Balaji, Pavan 02 Apr '15

02 Apr '15

There's already a ticket on the Forum trac for deprecating this and replacing it with a better function that, at the very least, takes a communicator argument. This function the way it is, is pretty useless, but is heavily used, unfortunately. -- Pavan > On Apr 2, 2015, at 1:07 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > FWIW, this function is described as "Cartesian Convenience Function" > and "helps the user select a balanced distribution of processes per > coordinate direction", which means that it really isn't required if > the user knows math. > > Obviously, your case is trivially solved because you already know > sqrt(nnodes), but I'm sure you are not using it this way in the real > application. However, there is nothing stopping you from writing a > superior prime factorization routine than MPICH, or whatever is > necessary to get behavior you want. > > Given the number of bugs in this function I've seen reported over the > years, I am inclined to ask the MPI Forum to deprecate it and > encourage users to do the math themselves, since it seems more often > than not that they can do better. > > Best, > > Jeff > > On Tue, Mar 31, 2015 at 12:10 AM, Valery <valeryweber(a)hotmail.com> wrote: >> Dear All >> >> I noticed that MPI_DIMS_CREATE cannot split eg >> 361 >> into a 19 * 19 processor grid. Is that a feature? >> >> The code follows. >> >> I used >> MPICH-3.1.4 >> gcc-4.9.2 >> >> valery >> >> >> cat mpi_dims.f90 >> program test >> use mpi >> implicit none >> integer :: ierr, nnodes, ndims, dims(2), i >> call MPI_INIT( ierr ) >> ndims = 2 >> do i = 1, 200 >> nnodes = i**2 >> dims(:) = 0 >> call MPI_DIMS_CREATE( nnodes, ndims, dims, ierr ) >> if( dims(1) /= i ) write(*,*) i, dims >> enddo >> call MPI_FINALIZE(ierr) >> end program test >> >> mpif90 mpi_dims.f90 >> >> >> mpiexec -n 1 ./a.out >> 19 361 1 >> 41 1681 1 >> 43 1849 1 >> 71 5041 1 >> 73 5329 1 >> 79 6241 1 >> 83 6889 1 >> 89 7921 1 >> 137 18769 1 >> 139 19321 1 >> 149 22201 1 >> 151 22801 1 >> 157 24649 1 >> 163 26569 1 >> 167 27889 1 >> 173 29929 1 >> 179 32041 1 >> 181 32761 1 >> >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] MPI_DIMS_CREATE
by Jeff Hammond 02 Apr '15

02 Apr '15

FWIW, this function is described as "Cartesian Convenience Function" and "helps the user select a balanced distribution of processes per coordinate direction", which means that it really isn't required if the user knows math. Obviously, your case is trivially solved because you already know sqrt(nnodes), but I'm sure you are not using it this way in the real application. However, there is nothing stopping you from writing a superior prime factorization routine than MPICH, or whatever is necessary to get behavior you want. Given the number of bugs in this function I've seen reported over the years, I am inclined to ask the MPI Forum to deprecate it and encourage users to do the math themselves, since it seems more often than not that they can do better. Best, Jeff On Tue, Mar 31, 2015 at 12:10 AM, Valery <valeryweber(a)hotmail.com> wrote: > Dear All > > I noticed that MPI_DIMS_CREATE cannot split eg > 361 > into a 19 * 19 processor grid. Is that a feature? > > The code follows. > > I used > MPICH-3.1.4 > gcc-4.9.2 > > valery > > > cat mpi_dims.f90 > program test > use mpi > implicit none > integer :: ierr, nnodes, ndims, dims(2), i > call MPI_INIT( ierr ) > ndims = 2 > do i = 1, 200 > nnodes = i**2 > dims(:) = 0 > call MPI_DIMS_CREATE( nnodes, ndims, dims, ierr ) > if( dims(1) /= i ) write(*,*) i, dims > enddo > call MPI_FINALIZE(ierr) > end program test > > mpif90 mpi_dims.f90 > > > mpiexec -n 1 ./a.out > 19 361 1 > 41 1681 1 > 43 1849 1 > 71 5041 1 > 73 5329 1 > 79 6241 1 > 83 6889 1 > 89 7921 1 > 137 18769 1 > 139 19321 1 > 149 22201 1 > 151 22801 1 > 157 24649 1 > 163 26569 1 > 167 27889 1 > 173 29929 1 > 179 32041 1 > 181 32761 1 > > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/ _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] MPI process binding on SunOS systems
by Aurélien Larcher 01 Apr '15

01 Apr '15

Hi Pavan, thank you for your answer. I get this output: larcher@na75:> HYDRA_TOPO_DEBUG=1 mpiexec -n 8 -bind-to hwthread -map-by core /bin/true | sort process 0 binding: 1 0 0 0 0 0 0 0 process 1 binding: 0 1 0 0 0 0 0 0 process 2 binding: 0 0 1 0 0 0 0 0 process 3 binding: 0 0 0 1 0 0 0 0 process 4 binding: 0 0 0 0 1 0 0 0 process 5 binding: 0 0 0 0 0 1 0 0 process 6 binding: 0 0 0 0 0 0 1 0 process 7 binding: 0 0 0 0 0 0 0 1 larcher@na75:> HYDRA_TOPO_DEBUG=1 mpiexec -n 4 -bind-to hwthread -map-by core /bin/true | sort process 0 binding: 1 0 0 0 0 0 0 0 process 1 binding: 0 1 0 0 0 0 0 0 process 2 binding: 0 0 1 0 0 0 0 0 process 3 binding: 0 0 0 1 0 0 0 0 which is exactly what I need, thank you ! Also passing -bind-to core:1 is suitable. Best, Aurelien On Wed, Apr 1, 2015 at 7:28 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > Try this: > > HYDRA_TOPO_DEBUG=1 mpiexec -n 8 -bind-to hwthread -map-by core /bin/true > | sort > > -- Pavan > > > On Apr 1, 2015, at 12:26 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > > > > > This is not linux specific. It's following whatever order the OS gives > it. You might want to look at the -map-by option for better controlling > the processes in the way you are looking for. > > > > -- Pavan > > > >> On Apr 1, 2015, at 11:47 AM, Aurélien Larcher < > aurelien.larcher(a)gmail.com> wrote: > >> > >> Hi Rajeev, > >> thank you for the pointer, actually this page leads me to another > question. > >> What is exactly the policy for binding by hwthreads ? > >> > >> I can see that: > >> > >> larcher@na75:> HYDRA_TOPO_DEBUG=1 mpiexec -n 8 -bind-to hwthread > /bin/true | sort > >> process 0 binding: 1 0 0 0 0 0 0 0 > >> process 1 binding: 0 0 0 0 1 0 0 0 > >> process 2 binding: 0 1 0 0 0 0 0 0 > >> process 3 binding: 0 0 0 0 0 1 0 0 > >> process 4 binding: 0 0 1 0 0 0 0 0 > >> process 5 binding: 0 0 0 0 0 0 1 0 > >> process 6 binding: 0 0 0 1 0 0 0 0 > >> process 7 binding: 0 0 0 0 0 0 0 1 > >> > >> Which seems unfortunate because since the processor is a quad core with > hyperthreading the same physical core will get the first two threads. > >> > >> larcher@na75:> psrinfo -pv > >> The physical processor has 4 cores and 8 virtual processors (0-7) > >> The core has 2 virtual processors (0 4) > >> The core has 2 virtual processors (1 5) > >> The core has 2 virtual processors (2 6) > >> The core has 2 virtual processors (3 7) > >> x86 (GenuineIntel 206A7 family 6 model 42 step 7 clock 3392 MHz) > >> Intel(r) Core(tm) i7-2600 CPU @ 3.40GHz > >> > >> > >> This is confirmed by: > >> > >> HYDRA_TOPO_DEBUG=1 mpiexec -n 4 -bind-to hwthread /bin/true | sort > >> process 0 binding: 1 0 0 0 0 0 0 0 > >> process 1 binding: 0 0 0 0 1 0 0 0 > >> process 2 binding: 0 1 0 0 0 0 0 0 > >> process 3 binding: 0 0 0 0 0 1 0 0 > >> > >> Is it due to a Linux-specific numbering of logical cores ? > >> > >> Thank you, > >> > >> Aurelien > >> > >> > >> > >> > >> On Wed, Apr 1, 2015 at 6:18 PM, Thakur, Rajeev <thakur(a)mcs.anl.gov> > wrote: > >> Yes, see > https://wiki.mpich.org/mpich/index.php/Using_the_Hydra_Process_Manager#Proc… > >> > >> Rajeev > >> > >> > >> On Apr 1, 2015, at 11:14 AM, Aurélien Larcher < > aurelien.larcher(a)gmail.com> > >> wrote: > >> > >>> Hi, > >>> running parallel code on my workstation (with OpenIndiana) I > discovered that MPI processes were migrated on a regular basis from one > core to another. > >>> > >>> On SunOS systems the command 'pbind' allows binding a process to a > specific core. > >>> So I am wondering if binding automatically each process to the next > available core is supported directly from MPICH ? > >>> > >>> Best regards > >>> > >>> Aurelien > >>> > >>> -- > >>> > ------------------------------------------------------------------------------- > >>> LARCHER Aurélien | KTH, School of Computer Science and > Communication > >>> Work: +46 (0) 8 790 71 42 | Lindstedtsvägen 5, Plan 4, 100 44 > Stockholm, SWEDEN > >>> > ------------------------------------------------------------------------------- > >>> _______________________________________________ > >>> discuss mailing list discuss(a)mpich.org > >>> To manage subscription options or unsubscribe: > >>> https://lists.mpich.org/mailman/listinfo/discuss > >> > >> _______________________________________________ > >> discuss mailing list discuss(a)mpich.org > >> To manage subscription options or unsubscribe: > >> https://lists.mpich.org/mailman/listinfo/discuss > >> > >> > >> > >> -- > >> > ------------------------------------------------------------------------------- > >> LARCHER Aurélien | KTH, School of Computer Science and > Communication > >> Work: +46 (0) 8 790 71 42 | Lindstedtsvägen 5, Plan 4, 100 44 > Stockholm, SWEDEN > >> > ------------------------------------------------------------------------------- > >> _______________________________________________ > >> discuss mailing list discuss(a)mpich.org > >> To manage subscription options or unsubscribe: > >> https://lists.mpich.org/mailman/listinfo/discuss > > > > -- > > Pavan Balaji ✉️ > > http://www.mcs.anl.gov/~balaji > > > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > -- > Pavan Balaji ✉️ > http://www.mcs.anl.gov/~balaji > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- ------------------------------------------------------------------------------- LARCHER Aurélien | KTH, School of Computer Science and Communication Work: +46 (0) 8 790 71 42 | Lindstedtsvägen 5, Plan 4, 100 44 Stockholm, SWEDEN ------------------------------------------------------------------------------- _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] MPI process binding on SunOS systems
by Balaji, Pavan 01 Apr '15

01 Apr '15

Try this: HYDRA_TOPO_DEBUG=1 mpiexec -n 8 -bind-to hwthread -map-by core /bin/true | sort -- Pavan > On Apr 1, 2015, at 12:26 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > > This is not linux specific. It's following whatever order the OS gives it. You might want to look at the -map-by option for better controlling the processes in the way you are looking for. > > -- Pavan > >> On Apr 1, 2015, at 11:47 AM, Aurélien Larcher <aurelien.larcher(a)gmail.com> wrote: >> >> Hi Rajeev, >> thank you for the pointer, actually this page leads me to another question. >> What is exactly the policy for binding by hwthreads ? >> >> I can see that: >> >> larcher@na75:> HYDRA_TOPO_DEBUG=1 mpiexec -n 8 -bind-to hwthread /bin/true | sort >> process 0 binding: 1 0 0 0 0 0 0 0 >> process 1 binding: 0 0 0 0 1 0 0 0 >> process 2 binding: 0 1 0 0 0 0 0 0 >> process 3 binding: 0 0 0 0 0 1 0 0 >> process 4 binding: 0 0 1 0 0 0 0 0 >> process 5 binding: 0 0 0 0 0 0 1 0 >> process 6 binding: 0 0 0 1 0 0 0 0 >> process 7 binding: 0 0 0 0 0 0 0 1 >> >> Which seems unfortunate because since the processor is a quad core with hyperthreading the same physical core will get the first two threads. >> >> larcher@na75:> psrinfo -pv >> The physical processor has 4 cores and 8 virtual processors (0-7) >> The core has 2 virtual processors (0 4) >> The core has 2 virtual processors (1 5) >> The core has 2 virtual processors (2 6) >> The core has 2 virtual processors (3 7) >> x86 (GenuineIntel 206A7 family 6 model 42 step 7 clock 3392 MHz) >> Intel(r) Core(tm) i7-2600 CPU @ 3.40GHz >> >> >> This is confirmed by: >> >> HYDRA_TOPO_DEBUG=1 mpiexec -n 4 -bind-to hwthread /bin/true | sort >> process 0 binding: 1 0 0 0 0 0 0 0 >> process 1 binding: 0 0 0 0 1 0 0 0 >> process 2 binding: 0 1 0 0 0 0 0 0 >> process 3 binding: 0 0 0 0 0 1 0 0 >> >> Is it due to a Linux-specific numbering of logical cores ? >> >> Thank you, >> >> Aurelien >> >> >> >> >> On Wed, Apr 1, 2015 at 6:18 PM, Thakur, Rajeev <thakur(a)mcs.anl.gov> wrote: >> Yes, see https://wiki.mpich.org/mpich/index.php/Using_the_Hydra_Process_Manager#Proc… >> >> Rajeev >> >> >> On Apr 1, 2015, at 11:14 AM, Aurélien Larcher <aurelien.larcher(a)gmail.com> >> wrote: >> >>> Hi, >>> running parallel code on my workstation (with OpenIndiana) I discovered that MPI processes were migrated on a regular basis from one core to another. >>> >>> On SunOS systems the command 'pbind' allows binding a process to a specific core. >>> So I am wondering if binding automatically each process to the next available core is supported directly from MPICH ? >>> >>> Best regards >>> >>> Aurelien >>> >>> -- >>> ------------------------------------------------------------------------------- >>> LARCHER Aurélien | KTH, School of Computer Science and Communication >>> Work: +46 (0) 8 790 71 42 | Lindstedtsvägen 5, Plan 4, 100 44 Stockholm, SWEDEN >>> ------------------------------------------------------------------------------- >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> >> >> >> -- >> ------------------------------------------------------------------------------- >> LARCHER Aurélien | KTH, School of Computer Science and Communication >> Work: +46 (0) 8 790 71 42 | Lindstedtsvägen 5, Plan 4, 100 44 Stockholm, SWEDEN >> ------------------------------------------------------------------------------- >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > > -- > Pavan Balaji ✉️ > http://www.mcs.anl.gov/~balaji > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] MPI process binding on SunOS systems
by Balaji, Pavan 01 Apr '15

01 Apr '15

This is not linux specific. It's following whatever order the OS gives it. You might want to look at the -map-by option for better controlling the processes in the way you are looking for. -- Pavan > On Apr 1, 2015, at 11:47 AM, Aurélien Larcher <aurelien.larcher(a)gmail.com> wrote: > > Hi Rajeev, > thank you for the pointer, actually this page leads me to another question. > What is exactly the policy for binding by hwthreads ? > > I can see that: > > larcher@na75:> HYDRA_TOPO_DEBUG=1 mpiexec -n 8 -bind-to hwthread /bin/true | sort > process 0 binding: 1 0 0 0 0 0 0 0 > process 1 binding: 0 0 0 0 1 0 0 0 > process 2 binding: 0 1 0 0 0 0 0 0 > process 3 binding: 0 0 0 0 0 1 0 0 > process 4 binding: 0 0 1 0 0 0 0 0 > process 5 binding: 0 0 0 0 0 0 1 0 > process 6 binding: 0 0 0 1 0 0 0 0 > process 7 binding: 0 0 0 0 0 0 0 1 > > Which seems unfortunate because since the processor is a quad core with hyperthreading the same physical core will get the first two threads. > > larcher@na75:> psrinfo -pv > The physical processor has 4 cores and 8 virtual processors (0-7) > The core has 2 virtual processors (0 4) > The core has 2 virtual processors (1 5) > The core has 2 virtual processors (2 6) > The core has 2 virtual processors (3 7) > x86 (GenuineIntel 206A7 family 6 model 42 step 7 clock 3392 MHz) > Intel(r) Core(tm) i7-2600 CPU @ 3.40GHz > > > This is confirmed by: > > HYDRA_TOPO_DEBUG=1 mpiexec -n 4 -bind-to hwthread /bin/true | sort > process 0 binding: 1 0 0 0 0 0 0 0 > process 1 binding: 0 0 0 0 1 0 0 0 > process 2 binding: 0 1 0 0 0 0 0 0 > process 3 binding: 0 0 0 0 0 1 0 0 > > Is it due to a Linux-specific numbering of logical cores ? > > Thank you, > > Aurelien > > > > > On Wed, Apr 1, 2015 at 6:18 PM, Thakur, Rajeev <thakur(a)mcs.anl.gov> wrote: > Yes, see https://wiki.mpich.org/mpich/index.php/Using_the_Hydra_Process_Manager#Proc… > > Rajeev > > > On Apr 1, 2015, at 11:14 AM, Aurélien Larcher <aurelien.larcher(a)gmail.com> > wrote: > > > Hi, > > running parallel code on my workstation (with OpenIndiana) I discovered that MPI processes were migrated on a regular basis from one core to another. > > > > On SunOS systems the command 'pbind' allows binding a process to a specific core. > > So I am wondering if binding automatically each process to the next available core is supported directly from MPICH ? > > > > Best regards > > > > Aurelien > > > > -- > > ------------------------------------------------------------------------------- > > LARCHER Aurélien | KTH, School of Computer Science and Communication > > Work: +46 (0) 8 790 71 42 | Lindstedtsvägen 5, Plan 4, 100 44 Stockholm, SWEDEN > > ------------------------------------------------------------------------------- > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > > > > -- > ------------------------------------------------------------------------------- > LARCHER Aurélien | KTH, School of Computer Science and Communication > Work: +46 (0) 8 790 71 42 | Lindstedtsvägen 5, Plan 4, 100 44 Stockholm, SWEDEN > ------------------------------------------------------------------------------- > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] MPI process binding on SunOS systems
by Aurélien Larcher 01 Apr '15

01 Apr '15

Hi Rajeev, thank you for the pointer, actually this page leads me to another question. What is exactly the policy for binding by hwthreads ? I can see that: larcher@na75:> HYDRA_TOPO_DEBUG=1 mpiexec -n 8 -bind-to hwthread /bin/true | sort process 0 binding: 1 0 0 0 0 0 0 0 process 1 binding: 0 0 0 0 1 0 0 0 process 2 binding: 0 1 0 0 0 0 0 0 process 3 binding: 0 0 0 0 0 1 0 0 process 4 binding: 0 0 1 0 0 0 0 0 process 5 binding: 0 0 0 0 0 0 1 0 process 6 binding: 0 0 0 1 0 0 0 0 process 7 binding: 0 0 0 0 0 0 0 1 Which seems unfortunate because since the processor is a quad core with hyperthreading the same physical core will get the first two threads. larcher@na75:> psrinfo -pv The physical processor has 4 cores and 8 virtual processors (0-7) The core has 2 virtual processors (0 4) The core has 2 virtual processors (1 5) The core has 2 virtual processors (2 6) The core has 2 virtual processors (3 7) x86 (GenuineIntel 206A7 family 6 model 42 step 7 clock 3392 MHz) Intel(r) Core(tm) i7-2600 CPU @ 3.40GHz This is confirmed by: HYDRA_TOPO_DEBUG=1 mpiexec -n 4 -bind-to hwthread /bin/true | sort process 0 binding: 1 0 0 0 0 0 0 0 process 1 binding: 0 0 0 0 1 0 0 0 process 2 binding: 0 1 0 0 0 0 0 0 process 3 binding: 0 0 0 0 0 1 0 0 Is it due to a Linux-specific numbering of logical cores ? Thank you, Aurelien On Wed, Apr 1, 2015 at 6:18 PM, Thakur, Rajeev <thakur(a)mcs.anl.gov> wrote: > Yes, see > https://wiki.mpich.org/mpich/index.php/Using_the_Hydra_Process_Manager#Proc… > > Rajeev > > > On Apr 1, 2015, at 11:14 AM, Aurélien Larcher <aurelien.larcher(a)gmail.com> > wrote: > > > Hi, > > running parallel code on my workstation (with OpenIndiana) I discovered > that MPI processes were migrated on a regular basis from one core to > another. > > > > On SunOS systems the command 'pbind' allows binding a process to a > specific core. > > So I am wondering if binding automatically each process to the next > available core is supported directly from MPICH ? > > > > Best regards > > > > Aurelien > > > > -- > > > ------------------------------------------------------------------------------- > > LARCHER Aurélien | KTH, School of Computer Science and > Communication > > Work: +46 (0) 8 790 71 42 | Lindstedtsvägen 5, Plan 4, 100 44 > Stockholm, SWEDEN > > > ------------------------------------------------------------------------------- > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- ------------------------------------------------------------------------------- LARCHER Aurélien | KTH, School of Computer Science and Communication Work: +46 (0) 8 790 71 42 | Lindstedtsvägen 5, Plan 4, 100 44 Stockholm, SWEDEN ------------------------------------------------------------------------------- _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] MPI process binding on SunOS systems
by Thakur, Rajeev 01 Apr '15

01 Apr '15

Yes, see https://wiki.mpich.org/mpich/index.php/Using_the_Hydra_Process_Manager#Proc… Rajeev On Apr 1, 2015, at 11:14 AM, Aurélien Larcher <aurelien.larcher(a)gmail.com> wrote: > Hi, > running parallel code on my workstation (with OpenIndiana) I discovered that MPI processes were migrated on a regular basis from one core to another. > > On SunOS systems the command 'pbind' allows binding a process to a specific core. > So I am wondering if binding automatically each process to the next available core is supported directly from MPICH ? > > Best regards > > Aurelien > > -- > ------------------------------------------------------------------------------- > LARCHER Aurélien | KTH, School of Computer Science and Communication > Work: +46 (0) 8 790 71 42 | Lindstedtsvägen 5, Plan 4, 100 44 Stockholm, SWEDEN > ------------------------------------------------------------------------------- > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0