Re: [OMPI devel] Fixes to OpenMPI-1.4.2 for PGI compilers
Hello Larry, * Larry Baker wrote on Wed, Aug 18, 2010 at 12:26:39AM CEST: > I patched OpenMPI 1.4.2 to fix some problems/warnings when using the > PGI compilers. FWIW, if there are fixes suitable for upstream Libtool in your changes, we would be glad if you could send them as bug reports or even 'diff -u' patches to the bug-libtool at gnu.org list. Line numbers don't help because they change too quickly, and issues might have been fixed in the git version of Libtool already. Thanks, Ralf
[OMPI devel] [PATCH] openmpi: get it built with newer autoconf
From: Sebastian Andrzej Siewior Reported as Debian bug #592892. AS_VAR_GET missbehaves in newer autoconf. Since it is deprecated switch to AS_VAR_COPY which gets things done right. Both are cursed. Signed-off-by: Sebastian Andrzej Siewior --- config/f77_get_alignment.m4 |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/config/f77_get_alignment.m4 b/config/f77_get_alignment.m4 index aa3d318..ba1fb96 100644 --- a/config/f77_get_alignment.m4 +++ b/config/f77_get_alignment.m4 @@ -90,7 +90,7 @@ EOF AC_MSG_ERROR([Could not determine alignment of $1])])]) rm -rf conftest*]) -$2=AS_VAR_GET([type_var]) +AS_VAR_COPY([$2], [type_var]) AS_VAR_POPDEF([type_var])dnl OMPI_VAR_SCOPE_POP ]) -- 1.5.6.5
[OMPI devel] Fwd: [all-osl-users] Outage of the OSL NFS server
FYI (milliways = www.open-mpi.org). Begin forwarded message: > From: DongInn Kim > Date: August 18, 2010 8:39:20 AM PDT > Subject: [all-osl-users] Outage of the OSL NFS server > > There is the NFS server migration in the OSL. > > We will migrate /l/osl/* to the new server (deep-thought) on Aug 20 and we > expect the following services to be unavailable for an hour. > > Date: Friday, Aug 20, 2010 > TIme: > - 5:00am-6:00am Pacific US time > - 6:00am-7:00am Mountain US time > - 7:00am-8:00am Central US time > - 8:00am-9:00am Eastern US time > - 12:00pm-1:00pm GMT > Unavailable services: > - All the websites sitting on NFS. > http://www.open-mpi.org > http://www.osl.iu.edu > http://www.scalabletools.org > etc > - License servers > - Module features to load up or unload some specific versions of software > > > Due to the recent malfunction to the NFS server connection on milliways, we > need to reboot milliways at the same time(8AM E.T.) and it will take about > 10~15 mins. > During the reboot of milliways, the following services would not be available: > - web > - mysql/postgresql > - mail / archive > - mailman > - jabber > > Please let me know if you have any issues or question about the outage. > > Regards, > > -- DongInn Kim > > -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] [PATCH] openmpi: get it built with newer autoconf
Thanks for the patch! With a quick grep, I actually see 16 uses of AS_VAR_GET. Do the other 15 cases not cause problems? On Aug 18, 2010, at 7:59 AM, Sebastian Andrzej Siewior wrote: > From: Sebastian Andrzej Siewior > > Reported as Debian bug #592892. AS_VAR_GET missbehaves in newer > autoconf. Since it is deprecated switch to AS_VAR_COPY which gets things > done right. Both are cursed. > > Signed-off-by: Sebastian Andrzej Siewior > --- > config/f77_get_alignment.m4 |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/config/f77_get_alignment.m4 b/config/f77_get_alignment.m4 > index aa3d318..ba1fb96 100644 > --- a/config/f77_get_alignment.m4 > +++ b/config/f77_get_alignment.m4 > @@ -90,7 +90,7 @@ EOF > AC_MSG_ERROR([Could not determine alignment of $1])])]) > rm -rf conftest*]) > > -$2=AS_VAR_GET([type_var]) > +AS_VAR_COPY([$2], [type_var]) > AS_VAR_POPDEF([type_var])dnl > OMPI_VAR_SCOPE_POP > ]) > -- > 1.5.6.5 > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
[OMPI devel] knem_dma_min
In mca_btl_sm_get_sync(), I see this: /* Use the DMA flag if knem supports it *and* the segment length is greater than the cutoff. Note that if the knem_dma_min value is 0 (i.e., the MCA param was set to 0), the segment size will never be larger than it, so DMA will never be used. */ icopy.flags = 0; if (mca_btl_sm_component.knem_dma_min <= dst->seg_len) { icopy.flags = mca_btl_sm_component.knem_dma_flag; } I'm going to poke around some more, but this doesn't on the surface make sense to me. If knem_dma_min==0, it would seem as though the segment size will *always* be at least that large and DMA will *always* be used (if supported).
Re: [OMPI devel] knem_dma_min
Eugene Loh wrote: In mca_btl_sm_get_sync(), I see this: /* Use the DMA flag if knem supports it *and* the segment length is greater than the cutoff. Note that if the knem_dma_min value is 0 (i.e., the MCA param was set to 0), the segment size will never be larger than it, so DMA will never be used. */ icopy.flags = 0; if (mca_btl_sm_component.knem_dma_min <= dst->seg_len) { icopy.flags = mca_btl_sm_component.knem_dma_flag; } I'm going to poke around some more, but this doesn't on the surface make sense to me. If knem_dma_min==0, it would seem as though the segment size will *always* be at least that large and DMA will *always* be used (if supported). Answering my own question (or guessing, in any case), maybe the code is okay but the comment is misleading. If knem_dma_min==0, then mca_btl_sm_component_init() sets knem_dma_flag to 0. So, the seg_len test passes, but it has no effect.
Re: [OMPI devel] [PATCH] openmpi: get it built with newer autoconf
Hello, * Jeff Squyres wrote on Wed, Aug 18, 2010 at 06:35:22PM CEST: > > With a quick grep, I actually see 16 uses of AS_VAR_GET. Do the other > 15 cases not cause problems? Whether or not, since AS_VAR_GET is undocumented (and inefficient, and now also buggy), it's prudent to replace them all with either AS_VAR_COPY or AS_VAR_IF as appropriate. Cheers, Ralf
[OMPI devel] Fwd: [all-osl-users] Outage of the OSL NFS server
This means that SVN and Trac will be out as well. Begin forwarded message: > From: DongInn Kim > Date: August 18, 2010 11:31:51 AM PDT > To: all-osl-us...@osl.iu.edu > Cc: Bruce Shing-Shong , Rob Henderson > Subject: Re: [all-osl-users] Outage of the OSL NFS server > > We found that we need to load up a new kernel on all the OSL server machines > and this is the perfect timing to reboot them to load up the new kernel. > > We would like to use the NFS outage time for rebooting the OSL server > machines. > > The following servers would be rebooted: > - sourcehaven > - milliways > - rontok > - deep-thought > - wowbagger > - eddie > - vogon > - magrathea > - gibson > > Please let me know if you have any concerns or questions about the reboot. > > Regards, > > On Aug 18, 2010, at 11:39 AM, DongInn Kim wrote: > >> There is the NFS server migration in the OSL. >> >> We will migrate /l/osl/* to the new server (deep-thought) on Aug 20 and we >> expect the following services to be unavailable for an hour. >> >> Date: Friday, Aug 20, 2010 >> TIme: >> - 5:00am-6:00am Pacific US time >> - 6:00am-7:00am Mountain US time >> - 7:00am-8:00am Central US time >> - 8:00am-9:00am Eastern US time >> - 12:00pm-1:00pm GMT >> Unavailable services: >> - All the websites sitting on NFS. >> http://www.open-mpi.org >> http://www.osl.iu.edu >> http://www.scalabletools.org >> etc >> - License servers >> - Module features to load up or unload some specific versions of software >> >> >> Due to the recent malfunction to the NFS server connection on milliways, we >> need to reboot milliways at the same time(8AM E.T.) and it will take about >> 10~15 mins. >> During the reboot of milliways, the following services would not be >> available: >> - web >> - mysql/postgresql >> - mail / archive >> - mailman >> - jabber >> >> Please let me know if you have any issues or question about the outage. >> >> Regards, >> >> -- DongInn Kim >> > > -- DongInn Kim > > > > -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [OMPI devel] knem_dma_min
Le 18/08/2010 19:21, Eugene Loh a écrit : > Eugene Loh wrote: > >> In mca_btl_sm_get_sync(), I see this: >> /* Use the DMA flag if knem supports it *and* the segment length >>is greater than the cutoff. Note that if the knem_dma_min >>value is 0 (i.e., the MCA param was set to 0), the segment size >>will never be larger than it, so DMA will never be used. */ >> icopy.flags = 0; >> if (mca_btl_sm_component.knem_dma_min <= dst->seg_len) { >> icopy.flags = mca_btl_sm_component.knem_dma_flag; >> } >> >> I'm going to poke around some more, but this doesn't on the surface >> make sense to me. If knem_dma_min==0, it would seem as though the >> segment size will *always* be at least that large and DMA will >> *always* be used (if supported). > > Answering my own question (or guessing, in any case), maybe the code > is okay but the comment is misleading. If knem_dma_min==0, then > mca_btl_sm_component_init() sets knem_dma_flag to 0. So, the seg_len > test passes, but it has no effect. Yes, your understanding is correct. It looks like the comment was not properly updated last time we changed the meaning of knem_dma_min. Brice