[OMPI devel] RFC: Add two new verbose outputs to BML layer

2014-03-03 Thread Rolf vandeVaart 
WHAT: Add two new verbose outputs to BML layer

WHY: There are times that I really want to know which BTLs are being used.  
These verbose outputs can help with that.

WHERE: ompi/mca/bml/r2/bml_r2.c

TIMEOUT: COB Friday, 7 March 2014

MORE DETAIL: I have run into some cases where I have added to add some 
opal_outputs to figure out what is going on with respect to which BTLs are 
selected.  I thought it would be nice to make it part of the verbose output.  
The entire change is below.

Index: ompi/mca/bml/r2/bml_r2.c
===
--- ompi/mca/bml/r2/bml_r2.c  (revision 30911)
+++ ompi/mca/bml/r2/bml_r2.c   (working copy)
@@ -14,6 +14,7 @@
  * reserved.
  * Copyright (c) 2008-2009 Cisco Systems, Inc.  All rights reserved.
  * Copyright (c) 2013  Intel, Inc. All rights reserved
+ * Copyright (c) 2014  NVIDIA Corporation.  All rights reserved.
  * $COPYRIGHT$
  *
  * Additional copyrights may follow
@@ -250,10 +251,24 @@
 /* skip this btl if the exclusivity is less than the 
previous */
 if(bml_btl->btl->btl_exclusivity > btl->btl_exclusivity) {
 btl->btl_del_procs(btl, 1, , _endpoints[p]);
+opal_output_verbose(20, 
ompi_bml_base_framework.framework_output,
+"mca: bml: Not using %s btl to %s 
on node %s "
+"because %s btl has higher 
exclusivity (%d > %d)",
+
btl->btl_component->btl_version.mca_component_name,
+OMPI_NAME_PRINT(>proc_name), 
proc->proc_hostname,
+
bml_btl->btl->btl_component->btl_version.mca_component_name,
+bml_btl->btl->btl_exclusivity,
+btl->btl_exclusivity);
 continue;
 }
 }

+opal_output_verbose(5, 
ompi_bml_base_framework.framework_output,
+"mca: bml: Using %s btl to %s on node %s",
+
btl->btl_component->btl_version.mca_component_name,
+OMPI_NAME_PRINT(>proc_name),
+proc->proc_hostname);
+
 /* cache the endpoint on the proc */
 bml_btl = 
mca_bml_base_btl_array_insert(_endpoint->btl_send);
 bml_btl->btl = btl;





---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---

Re: [OMPI devel] Fix compiler warnings in FT code

2014-03-03 Thread Josh Hursey 
Yea. Those look fine. Thanks!


On Mon, Mar 3, 2014 at 10:42 AM, Adrian Reber  wrote:

> I will prepare a patch that moves the parameter initialization somewhere
> else
> and will not remove it. Do you think the other parts of the patch can be
> applied (without sstore_stage_select() removal)?
>
>
> On Mon, Mar 03, 2014 at 10:07:36AM -0600, Josh Hursey wrote:
> > It should probably be moved to the component initialization of the sstore
> > stage component since those parameters are how the user controls where to
> > store those files. I think there is an MCA registration function that is
> > called after component initialization - that would be the best spot, but
> I
> > do not remember how to set it up at the moment.
> >
> >
> >
> >
> > On Mon, Mar 3, 2014 at 7:25 AM, Adrian Reber  wrote:
> >
> > > I removed a complete function because it was not used:
> > >
> > > ../../../../../orte/mca/sstore/stage/sstore_stage_component.c: At top
> > > level:
> > > ../../../../../orte/mca/sstore/stage/sstore_stage_component.c:77:12:
> > > warning: 'sstore_stage_select' defined but not used [-Wunused-function]
> > >  static int sstore_stage_select (void)
> > >
> > > And grepping through the code it seems the compiler is right.
> > >
> > > Should we keep the code and maybe just #ifdef it out.
> > >
> > > On Mon, Mar 03, 2014 at 07:17:19AM -0600, Josh Hursey wrote:
> > > > It looks like you removed a number of sstore stage MCA parameters.
> Did
> > > they
> > > > move somewhere else? or do you have a different way to set those
> > > parameters?
> > > >
> > > > Other than that it looks good to me.
> > > >
> > > >
> > > > On Mon, Mar 3, 2014 at 5:29 AM, Adrian Reber 
> wrote:
> > > >
> > > > > I have a simple patch which fixes the remaining compiler warnings
> when
> > > > > running with '--with-ft':
> > > > >
> > > > >
> > > > >
> > >
> https://lisas.de/git/?p=open-mpi.git;a=commitdiff;h=4dee703a0a2e64972b0c35b7693c11a09f1fbe5f
> > > > >
> > > > > Does anybody see any problems with this patch?
> > > > >
> > > > > Adrian
> > > > > ___
> > > > > devel mailing list
> > > > > de...@open-mpi.org
> > > > > http://www.open-mpi.org/mailman/listinfo.cgi/devel
> > > ___
> > > devel mailing list
> > > de...@open-mpi.org
> > > http://www.open-mpi.org/mailman/listinfo.cgi/devel
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>



-- 
Joshua Hursey
Assistant Professor of Computer Science
University of Wisconsin-La Crosse
http://cs.uwlax.edu/~jjhursey

Re: [OMPI devel] mca_base_component_distill_checkpoint_ready variable

2014-03-03 Thread Hjelm, Nathan T 
Looks good to me.

-Nathan

On Monday, March 03, 2014 10:04 AM, devel [devel-boun...@open-mpi.org] on 
behalf of Adrian Reber [adr...@lisas.de] wrote:
> To: Open MPI Developers
> Subject: Re: [OMPI devel] mca_base_component_distill_checkpoint_ready   
> variable
> 
> On Fri, Feb 21, 2014 at 10:12:54AM -0700, Nathan Hjelm wrote:
>> On Fri, Feb 21, 2014 at 05:21:10PM +0100, Adrian Reber wrote:
>> > There is a variable in the FT code which is not defined and therefore
>> > currently #ifdef'd out.
>> >
>> > #if (OPAL_ENABLE_FT == 1) && (OPAL_ENABLE_FT_CR == 1)
>> > #ifdef ENABLE_FT_FIXED
>> > /* FIXME_FT
>> >  *
>> >  * the variable mca_base_component_distill_checkpoint_ready
>> >  * was removed by commit 8181c8273c486bba59b3dead324939eac1a58b8c 
>> > (r28237)
>> >  * "Introduce the MCA framework system. This formalizes the interface 
>> > frameworks must provide."
>> >  *
>> >  * */
>> > if (mca_base_component_distill_checkpoint_ready) {
>> > open_only_flags |= MCA_BASE_METADATA_PARAM_CHECKPOINT;
>> > }
>> > #endif /* ENABLE_FT_FIXED */
>> > #endif  /* (OPAL_ENABLE_FT == 1) && (OPAL_ENABLE_FT_CR == 1) */
>> >
>> >
>> > The variable 'mca_base_component_distill_checkpoint_ready' used to exist 
>> > but was removed
>> > with commit 'r28237':
>> >
>> > -#if (OPAL_ENABLE_FT == 1) && (OPAL_ENABLE_FT_CR == 1)
>> > -{
>> > -int param_id = -1;
>> > -int param_val = 0;
>> > -/*
>> > - * Extract supported mca parameters for selection contraints
>> > - * Supported Options:
>> > - *   - mca_base_component_distill_checkpoint_ready = Checkpoint 
>> > Ready
>> > - */
>> > -param_id = mca_base_param_reg_int_name("mca", 
>> > "base_component_distill_checkpoint_ready",
>> > -   "Distill only those 
>> > components that are Checkpoint Ready",
>> > -   false, false,
>> > -   0, _val);
>> > -if( 0 != param_val ) { /* Select Checkpoint Ready */
>> > -open_only_flags |= MCA_BASE_METADATA_PARAM_CHECKPOINT;
>> > -}
>> > -}
>> > -#endif  /* (OPAL_ENABLE_FT == 1) && (OPAL_ENABLE_FT_CR == 1) */
>> >
>> > The variable is defined in contrib/amca-param-sets/ft-enable-cr
>> >
>> > mca_base_component_distill_checkpoint_ready=1
>> >
>> > Looking at the name of other variable I would say it should be called
>> >
>> > opal_base_distill_checkpoint_ready
>> >
>> > and probably created with mca_base_var_register() or 
>> > mca_base_component_var_register().
>> >
>> > What would be the best place to create the variable so that it can be used 
>> > again in
>> > the FT code?
>>
>> Some variables are registered in opal/runtime/opal_params.c. That might
>> be a good place to add it.
> 
> I added in that file. What do you think of following patch:
> 
> https://lisas.de/git/?p=open-mpi.git;a=commitdiff;h=a9808e2c4bc765963796eb35878a2e238377
> 
> 
> Adrian

Re: [OMPI devel] 1.7.5rc1 failure: unresolved pthread calls

2014-03-03 Thread Hjelm, Nathan T 
Fixed on the trunk and CMR'ed to 1.7.5.

-Nathan

On Sunday, March 02, 2014 5:17 PM, devel [devel-boun...@open-mpi.org] on behalf 
of Paul Hargrove [phhargr...@lbl.gov] wrote:
> To: Open MPI Developers
> Subject: [OMPI devel] 1.7.5rc1 failure: unresolved pthread calls
> 
> The failure below (from OpenBSD5-amd64) shows unresolved calls to pthread 
> "setpshared" interfaces for mutex and condition vars.   Thesw were not part 
> of the initial POSIX threads specification, and therefore configure-time 
> check is required before these calls can safely be included.
> 
> Like my previous report (unresolved __sync_synchronize) this is from the 
> osc/sm component code, and there is no relation to VT (it just happens that 
> otfmerge-mpi is the first executable linked to libmpi).
> 
> -Paul
> 
> /home/phargrov/OMPI/openmpi-1.7.5rc1-openbsd5-amd64/BLD/ompi/contrib/vt/vt/../../../.libs/libmpi.a(osc_sm_component.o)(.text+0xba5):
>  In function `component_select':
> /home/phargrov/OMPI/openmpi-1.7.5rc1-openbsd5-amd64/openmpi-1.7.5rc1/ompi/mca/osc/sm/osc_sm_component.c:349:
>  undefined reference to `pthread_mutexattr_setpshared'
> /home/phargrov/OMPI/openmpi-1.7.5rc1-openbsd5-amd64/BLD/ompi/contrib/vt/vt/../../../.libs/libmpi.a(osc_sm_component.o)(.text+0xc14):/home/phargrov/OMPI/openmpi-1.7.5rc1-openbsd5-amd64/openmpi-1.7.5rc1/ompi/mca/osc/sm/osc_sm_component.c:358:
>  undefined reference to `pthread_condattr_setpshared'
> collect2: ld returned 1 exit status
> 
> 
> --
> Paul H. Hargrove  
> phhargr...@lbl.gov
> Future Technologies Group
> Computer and Data Sciences Department Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

Re: [OMPI devel] mca_base_component_distill_checkpoint_ready variable

2014-03-03 Thread Adrian Reber 
On Fri, Feb 21, 2014 at 10:12:54AM -0700, Nathan Hjelm wrote:
> On Fri, Feb 21, 2014 at 05:21:10PM +0100, Adrian Reber wrote:
> > There is a variable in the FT code which is not defined and therefore
> > currently #ifdef'd out.
> > 
> > #if (OPAL_ENABLE_FT == 1) && (OPAL_ENABLE_FT_CR == 1)
> > #ifdef ENABLE_FT_FIXED
> > /* FIXME_FT
> >  *
> >  * the variable mca_base_component_distill_checkpoint_ready
> >  * was removed by commit 8181c8273c486bba59b3dead324939eac1a58b8c 
> > (r28237)
> >  * "Introduce the MCA framework system. This formalizes the interface 
> > frameworks must provide."
> >  *
> >  * */
> > if (mca_base_component_distill_checkpoint_ready) {
> > open_only_flags |= MCA_BASE_METADATA_PARAM_CHECKPOINT;
> > }
> > #endif /* ENABLE_FT_FIXED */
> > #endif  /* (OPAL_ENABLE_FT == 1) && (OPAL_ENABLE_FT_CR == 1) */
> > 
> > 
> > The variable 'mca_base_component_distill_checkpoint_ready' used to exist 
> > but was removed
> > with commit 'r28237':
> > 
> > -#if (OPAL_ENABLE_FT == 1) && (OPAL_ENABLE_FT_CR == 1)
> > -{
> > -int param_id = -1;
> > -int param_val = 0;
> > -/*
> > - * Extract supported mca parameters for selection contraints
> > - * Supported Options:
> > - *   - mca_base_component_distill_checkpoint_ready = Checkpoint 
> > Ready
> > - */
> > -param_id = mca_base_param_reg_int_name("mca", 
> > "base_component_distill_checkpoint_ready",
> > -   "Distill only those 
> > components that are Checkpoint Ready", 
> > -   false, false,
> > -   0, _val);
> > -if( 0 != param_val ) { /* Select Checkpoint Ready */
> > -open_only_flags |= MCA_BASE_METADATA_PARAM_CHECKPOINT;
> > -}
> > -}
> > -#endif  /* (OPAL_ENABLE_FT == 1) && (OPAL_ENABLE_FT_CR == 1) */
> > 
> > The variable is defined in contrib/amca-param-sets/ft-enable-cr
> > 
> > mca_base_component_distill_checkpoint_ready=1
> > 
> > Looking at the name of other variable I would say it should be called
> > 
> > opal_base_distill_checkpoint_ready
> > 
> > and probably created with mca_base_var_register() or 
> > mca_base_component_var_register().
> > 
> > What would be the best place to create the variable so that it can be used 
> > again in
> > the FT code?
> 
> Some variables are registered in opal/runtime/opal_params.c. That might
> be a good place to add it.

I added in that file. What do you think of following patch:

https://lisas.de/git/?p=open-mpi.git;a=commitdiff;h=a9808e2c4bc765963796eb35878a2e238377


Adrian


pgpDPHILC7koS.pgp
Description: PGP signature

[OMPI devel] Change in default MCA parameter value

2014-03-03 Thread Ralph Castain 
Heads up...

 (In [30909]) Now that we are binding by default, the issue of #slots and what 
to do when oversubscribed has become a bit more complicated. This isn't a 
problem in managed environments as we are always provided an accurate 
assignment for the #slots, or when -host is used to define the allocation since 
we automatically assume one slot for every time a node is named.

The problem arises when a hostfile is used, and the user provides host names 
without specifying the slots= paramater. In these cases, we assign slots=1, but 
automatically allow oversubscription since that number isn't confirmed. We then 
provide a separate parameter by which the user can direct that we assign the 
number of slots based on the sensed hardware - e.g., by telling us to set the 
#slots equal to the #cores on each node. However, this has been set to "off" by 
default.

In order to make this a little less complex for the user, set the default such 
that we automatically set #slots equal to #cores (or #hwt's if 
use_hwthreads_as_cpus has been set) only for those cases where the user 
provides names in a hostfile but does not provide slot information.

Re: [OMPI devel] v1.7.5rc1 build failure: unresolved __sync_syncronize()

2014-03-03 Thread Hjelm, Nathan T 
Ok, I see whats happening. That component is calling a gcc specific memory 
barrier. I will replace it with the appropriate opal_atomic call.

-Nathan

On Sunday, March 02, 2014 5:12 PM, devel [devel-boun...@open-mpi.org] on behalf 
of Paul Hargrove [phhargr...@lbl.gov] wrote:
> To: Open MPI Developers
> Subject: [OMPI devel] v1.7.5rc1 build failure: unresolved __sync_syncronize()
> 
> With many testers still running at this time, the first to complete is a 
> failure report.
> 
> From a FreBSD-6/amd64 platform:
>   CCLD otfmerge-mpi
> /data/home/hargrove/OMPI/openmpi-1.7.5rc1-freebsd6-amd64/BLD/ompi/contrib/vt/vt/../../../.libs/libmpi.a(osc_sm
> _passive_target.o)(.text+0x18b): In function `lk_fetch32':
> /data/home/hargrove/OMPI/openmpi-1.7.5rc1-freebsd6-amd64/openmpi-1.7.5rc1/ompi/mca/osc/sm/:51:
>  undefined reference to `__sync_synchronize'
> 
> Keep in mind that with 99% certainty this has NOTHING to do with VT.  It just 
> happens thatotfmerge-mpi is the first executable linked with libmpi.  Rather 
> the fault lies with the __sync_synchronize call in osc_sm_passive_target.c.  
> The __sync_synchronize() call is not only gcc-specific, but didn't exist 
> prior to about gcc-4.1.  Surely there must be a opal call that should be used 
> here instead?
> 
> There is no reason to think this is specific to FreeBSD-6, but rather the use 
> of a gcc older than the addition of __sync_syncronize() seems the most likely 
> key to exposing the problem.  I suspect that as my non-gcc testers complete 
> (esp. PGI and Sun) this same issue will arise there.
> 
> 
> On Sat, Mar 1, 2014 at 6:13 PM, Ralph Castain 
> > wrote:
> In the usual place:
> 
> http://www.open-mpi.org/software/ompi/v1.7/
> 
> Please subject this to your best tests as we hope to roll this (plus bug 
> fixes) to 1.8.0 at the end of the month. This includes the new OSHMEM 
> support, plus a completely updated MPI-3 compliant one-sided implementation.
> 
> Scheduled release date: Mar 10
> 
> Thanks
> Ralph
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> 
> 
> 
> --
> Paul H. Hargrove  
> phhargr...@lbl.gov
> Future Technologies Group
> Computer and Data Sciences Department Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900

Re: [OMPI devel] Fix compiler warnings in FT code

2014-03-03 Thread Adrian Reber 
I will prepare a patch that moves the parameter initialization somewhere else
and will not remove it. Do you think the other parts of the patch can be
applied (without sstore_stage_select() removal)?


On Mon, Mar 03, 2014 at 10:07:36AM -0600, Josh Hursey wrote:
> It should probably be moved to the component initialization of the sstore
> stage component since those parameters are how the user controls where to
> store those files. I think there is an MCA registration function that is
> called after component initialization - that would be the best spot, but I
> do not remember how to set it up at the moment.
> 
> 
> 
> 
> On Mon, Mar 3, 2014 at 7:25 AM, Adrian Reber  wrote:
> 
> > I removed a complete function because it was not used:
> >
> > ../../../../../orte/mca/sstore/stage/sstore_stage_component.c: At top
> > level:
> > ../../../../../orte/mca/sstore/stage/sstore_stage_component.c:77:12:
> > warning: 'sstore_stage_select' defined but not used [-Wunused-function]
> >  static int sstore_stage_select (void)
> >
> > And grepping through the code it seems the compiler is right.
> >
> > Should we keep the code and maybe just #ifdef it out.
> >
> > On Mon, Mar 03, 2014 at 07:17:19AM -0600, Josh Hursey wrote:
> > > It looks like you removed a number of sstore stage MCA parameters. Did
> > they
> > > move somewhere else? or do you have a different way to set those
> > parameters?
> > >
> > > Other than that it looks good to me.
> > >
> > >
> > > On Mon, Mar 3, 2014 at 5:29 AM, Adrian Reber  wrote:
> > >
> > > > I have a simple patch which fixes the remaining compiler warnings when
> > > > running with '--with-ft':
> > > >
> > > >
> > > >
> > https://lisas.de/git/?p=open-mpi.git;a=commitdiff;h=4dee703a0a2e64972b0c35b7693c11a09f1fbe5f
> > > >
> > > > Does anybody see any problems with this patch?
> > > >
> > > > Adrian
> > > > ___
> > > > devel mailing list
> > > > de...@open-mpi.org
> > > > http://www.open-mpi.org/mailman/listinfo.cgi/devel
> > ___
> > devel mailing list
> > de...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] Fix compiler warnings in FT code

2014-03-03 Thread Josh Hursey 
It should probably be moved to the component initialization of the sstore
stage component since those parameters are how the user controls where to
store those files. I think there is an MCA registration function that is
called after component initialization - that would be the best spot, but I
do not remember how to set it up at the moment.




On Mon, Mar 3, 2014 at 7:25 AM, Adrian Reber  wrote:

> I removed a complete function because it was not used:
>
> ../../../../../orte/mca/sstore/stage/sstore_stage_component.c: At top
> level:
> ../../../../../orte/mca/sstore/stage/sstore_stage_component.c:77:12:
> warning: 'sstore_stage_select' defined but not used [-Wunused-function]
>  static int sstore_stage_select (void)
>
> And grepping through the code it seems the compiler is right.
>
> Should we keep the code and maybe just #ifdef it out.
>
> On Mon, Mar 03, 2014 at 07:17:19AM -0600, Josh Hursey wrote:
> > It looks like you removed a number of sstore stage MCA parameters. Did
> they
> > move somewhere else? or do you have a different way to set those
> parameters?
> >
> > Other than that it looks good to me.
> >
> >
> > On Mon, Mar 3, 2014 at 5:29 AM, Adrian Reber  wrote:
> >
> > > I have a simple patch which fixes the remaining compiler warnings when
> > > running with '--with-ft':
> > >
> > >
> > >
> https://lisas.de/git/?p=open-mpi.git;a=commitdiff;h=4dee703a0a2e64972b0c35b7693c11a09f1fbe5f
> > >
> > > Does anybody see any problems with this patch?
> > >
> > > Adrian
> > > ___
> > > devel mailing list
> > > de...@open-mpi.org
> > > http://www.open-mpi.org/mailman/listinfo.cgi/devel
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>



-- 
Joshua Hursey
Assistant Professor of Computer Science
University of Wisconsin-La Crosse
http://cs.uwlax.edu/~jjhursey

Re: [OMPI devel] v1.7.5rc1 posted

2014-03-03 Thread Jeff Squyres (jsquyres) 
On Mar 2, 2014, at 8:29 PM, Orion Poplawski  wrote:

> We're not honoring DESTDIR here:
> 
> make  install-data-hook
> make[6]: Entering directory
> `/builddir/build/BUILD/openmpi-1.7.5rc1/ompi/mpi/java/java'
> /usr/bin/mkdir -p /usr/lib64/openmpi/share/doc/openmpi/javadoc
> /usr/bin/mkdir: cannot create directory '/usr/lib64/openmpi': Permission
> denied
> cp -rp doc/* /usr/lib64/openmpi/share/doc/openmpi/javadoc
> make[6]: [jdoc-install] Error 1 (ignored)

Ouch!

My mistake; thanks for catching that -- I'll fix.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] autoconf warnings: openib BTL

2014-03-03 Thread Jeff Squyres (jsquyres) 
Can't you test for that at run-time?

I.e., can't you do the configure-time test to see if AF_IB exists, and if it 
does, do a run-time check to see if it's useful/supported in the kernel?  Or is 
there a reason not to do this (e.g., it would impose a performance penalty at 
run time because the check would need to be in the performance-critical code 
path)?



On Mar 2, 2014, at 11:02 PM, Vasily Filipov  wrote:

> some additional explanation  - it could be a situation when AF_IB is defined 
> in user space but kernel doesn't support it.
> 
> On 03-Mar-14 08:53, Vasily Filipov wrote:
>> Hi Jeff, 
>> I've committed the fixes (r30905). It is a problem to detect kernel 
>> defines (such as AF_IB ), so we have to use AC_RUN_IFELSE macro. 
>> 
>> Thanks, 
>> Vasily. 
>> 
>> On 27-Feb-14 17:09, Jeff Squyres (jsquyres) wrote: 
>>> I'm seeing this warning this morning: 
>>> 
>>> - 
>>> configure.ac:1139: warning: AC_RUN_IFELSE called without default to allow 
>>> cross c\ 
>>> ompiling 
>>> ../../lib/autoconf/general.m4:2748: AC_RUN_IFELSE is expanded from... 
>>> ../../lib/m4sugar/m4sh.m4:639: AS_IF is expanded from... 
>>> ompi/mca/btl/openib/configure.m4:37: MCA_ompi_btl_openib_CONFIG is expanded 
>>> from.\ 
>>> .. 
>>> config/ompi_mca.m4:571: MCA_CONFIGURE_M4_CONFIG_COMPONENT is expanded 
>>> from... 
>>> config/ompi_mca.m4:352: MCA_CONFIGURE_FRAMEWORK is expanded from... 
>>> config/ompi_mca.m4:252: MCA_CONFIGURE_PROJECT is expanded from... 
>>> config/ompi_mca.m4:39: OMPI_MCA is expanded from... 
>>> configure.ac:1139: the top level 
>>> - 
>>> 
>>> Is it necessary to AC_RUN_IFELSE here?  Is AC_CHECK_DECLS not sufficient 
>>> for some reason? 
>>> 
>>> It strikes me that this test you currently have in configure.m4 really 
>>> should be a run-time test, and that all you need in configure.m4 should be 
>>> an AC_CHECK_DECLS to see if AF_IB exists. 
>>> 
>> 
> 
> ___
> 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/

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r30906 - in trunk: . config

2014-03-03 Thread Jeff Squyres (jsquyres) 
More specifically, this goes back to the original question I asked long ago: if 
it is time to unify the fortran language CLI options (i.e., --disable-fortran 
instead of/in addition to --disable-mpi-fortran / --disable-oshmem-fortran).

I say this because by the logic from #1 below, if you have to 
--disable-mpi-fortran --disable-oshmem-fortran, that seems somewhat annoying.

...but then again, that might not even be right.  This requires someone to 
really re-think the options and come up with a good solution; what I said above 
is a gut reaction, and I haven't thought through the corner cases.

Regardless, for 1.7.x, my $0.02 is that the --disable-mpi-fortran switch should 
also disable OSHMEM Fortran bindings (unless --enable-oshmem-fortran was 
specified, in which case that would be an error).  Something Better can be done 
for trunk/v1.9.



On Mar 3, 2014, at 7:13 AM, "Jeff Squyres (jsquyres)"  
wrote:

> This commit breaks building without MPI Fortran support.  Note that I did 
> *NOT* specify --enable-oshmem-fortran:
> 
> -
> *** OSHMEM Configuration options
> checking if want SGI/Quadrix compatibility mode... yes
> checking if want OSHMEM API parameter checking... always
> checking if want pshmem_... yes
> checking if want to build OSHMEM fortran bindings... bad value 
> OMPI_WANT_FORTRAN_BINDINGS: (0)
> configure: WARNING: Your request to --enable-oshmem-fortran can only be 
> satisfied if fortran support is enabled in OMPI.
> You see this message for one of two reasons:
> 1. OMPI fortran support has been explicitly disabled via 
> --disable-mpi-fortran and OSHMEM fortran support was implicitly enabled by 
> default.
> 2. OMPI fortran support has been explicitly disabled via 
> --disable-mpi-fortran and OSHMEM fortran support was explicitly enabled with 
> --enable-oshmem-fortran.
> Configure will abort because you, a human, have asked for something that 
> cannot be provided.
> configure: error: Cannot continue
> -
> 
> On Mar 3, 2014, at 1:58 AM,  wrote:
> 
>> Author: miked (Mike Dubman)
>> Date: 2014-03-03 04:58:11 EST (Mon, 03 Mar 2014)
>> New Revision: 30906
>> URL: https://svn.open-mpi.org/trac/ompi/changeset/30906
>> 
>> Log:
>> OSHMEM: fix fortran binding
>> 
>> based on true story: 
>> http://www.open-mpi.org/community/lists/devel/2014/03/14262.php
>> 
>> fixed by Roman, reviewed by Igor/Mike
>> 
>> cmr=v1.7.5:reviewer=ompi-rm1.7
>> 
>> Text files modified: 
>>  trunk/config/oshmem_configure_options.m4 | 2 +- 
>>  
>>  trunk/configure.ac   | 2 +- 
>>  
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>> 
>> Modified: trunk/config/oshmem_configure_options.m4
>> ==
>> --- trunk/config/oshmem_configure_options.m4 Mon Mar  3 01:41:46 2014
>> (r30905)
>> +++ trunk/config/oshmem_configure_options.m4 2014-03-03 04:58:11 EST (Mon, 
>> 03 Mar 2014)  (r30906)
>> @@ -93,7 +93,7 @@
>> AC_ARG_ENABLE(oshmem-fortran,
>> AC_HELP_STRING([--enable-oshmem-fortran],
>>   [enable OSHMEM Fortran bindings (default: enabled if Fortran 
>> compiler found)]))
>> -if test "$enable_oshmem_fortran" != "no" -a "$ompi_fortran_happy" = 1; then
>> +if test "$enable_oshmem_fortran" != "no"; then
>> # If no OMPI FORTRAN, bail
>>   AS_IF([test $OMPI_WANT_FORTRAN_BINDINGS -eq 0 -a "$enable_oshmem" != "no"],
>>   [AC_MSG_RESULT([bad value OMPI_WANT_FORTRAN_BINDINGS: 
>> ($OMPI_WANT_FORTRAN_BINDINGS)])
>> 
>> Modified: trunk/configure.ac
>> ==
>> --- trunk/configure.ac   Mon Mar  3 01:41:46 2014(r30905)
>> +++ trunk/configure.ac   2014-03-03 04:58:11 EST (Mon, 03 Mar 2014)  
>> (r30906)
>> @@ -605,7 +605,7 @@
>> AM_CONDITIONAL(OSHMEM_BUILD_FORTRAN_BINDINGS,
>>[test "$ompi_fortran_happy" == "1" -a \
>>  "$OMPI_WANT_FORTRAN_BINDINGS" == "1" -a \
>> -  "$oshmem_fortran_enable" != "no"])
>> +  "$enable_oshmem_fortran" != "no"])
>> 
>> # checkpoint results
>> AC_CACHE_SAVE
>> ___
>> svn-full mailing list
>> svn-f...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/svn-full
> 
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> ___
> 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/

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r30906 - in trunk: . config

2014-03-03 Thread Jeff Squyres (jsquyres) 
This commit breaks building without MPI Fortran support.  Note that I did *NOT* 
specify --enable-oshmem-fortran:

-
*** OSHMEM Configuration options
checking if want SGI/Quadrix compatibility mode... yes
checking if want OSHMEM API parameter checking... always
checking if want pshmem_... yes
checking if want to build OSHMEM fortran bindings... bad value 
OMPI_WANT_FORTRAN_BINDINGS: (0)
configure: WARNING: Your request to --enable-oshmem-fortran can only be 
satisfied if fortran support is enabled in OMPI.
You see this message for one of two reasons:
1. OMPI fortran support has been explicitly disabled via --disable-mpi-fortran 
and OSHMEM fortran support was implicitly enabled by default.
2. OMPI fortran support has been explicitly disabled via --disable-mpi-fortran 
and OSHMEM fortran support was explicitly enabled with --enable-oshmem-fortran.
Configure will abort because you, a human, have asked for something that cannot 
be provided.
configure: error: Cannot continue
-

On Mar 3, 2014, at 1:58 AM,  wrote:

> Author: miked (Mike Dubman)
> Date: 2014-03-03 04:58:11 EST (Mon, 03 Mar 2014)
> New Revision: 30906
> URL: https://svn.open-mpi.org/trac/ompi/changeset/30906
> 
> Log:
> OSHMEM: fix fortran binding
> 
> based on true story: 
> http://www.open-mpi.org/community/lists/devel/2014/03/14262.php
> 
> fixed by Roman, reviewed by Igor/Mike
> 
> cmr=v1.7.5:reviewer=ompi-rm1.7
> 
> Text files modified: 
>   trunk/config/oshmem_configure_options.m4 | 2 +- 
>  
>   trunk/configure.ac   | 2 +- 
>  
>   2 files changed, 2 insertions(+), 2 deletions(-)
> 
> Modified: trunk/config/oshmem_configure_options.m4
> ==
> --- trunk/config/oshmem_configure_options.m4  Mon Mar  3 01:41:46 2014
> (r30905)
> +++ trunk/config/oshmem_configure_options.m4  2014-03-03 04:58:11 EST (Mon, 
> 03 Mar 2014)  (r30906)
> @@ -93,7 +93,7 @@
> AC_ARG_ENABLE(oshmem-fortran,
> AC_HELP_STRING([--enable-oshmem-fortran],
>[enable OSHMEM Fortran bindings (default: enabled if Fortran 
> compiler found)]))
> -if test "$enable_oshmem_fortran" != "no" -a "$ompi_fortran_happy" = 1; then
> +if test "$enable_oshmem_fortran" != "no"; then
> # If no OMPI FORTRAN, bail
>AS_IF([test $OMPI_WANT_FORTRAN_BINDINGS -eq 0 -a "$enable_oshmem" != "no"],
>[AC_MSG_RESULT([bad value OMPI_WANT_FORTRAN_BINDINGS: 
> ($OMPI_WANT_FORTRAN_BINDINGS)])
> 
> Modified: trunk/configure.ac
> ==
> --- trunk/configure.acMon Mar  3 01:41:46 2014(r30905)
> +++ trunk/configure.ac2014-03-03 04:58:11 EST (Mon, 03 Mar 2014)  
> (r30906)
> @@ -605,7 +605,7 @@
> AM_CONDITIONAL(OSHMEM_BUILD_FORTRAN_BINDINGS,
> [test "$ompi_fortran_happy" == "1" -a \
>   "$OMPI_WANT_FORTRAN_BINDINGS" == "1" -a \
> -  "$oshmem_fortran_enable" != "no"])
> +  "$enable_oshmem_fortran" != "no"])
> 
> # checkpoint results
> AC_CACHE_SAVE
> ___
> svn-full mailing list
> svn-f...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/svn-full


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r30905 - in trunk/ompi/mca/btl/openib: . connect

2014-03-03 Thread Jeff Squyres (jsquyres) 
Please note Open MPI standards state that for .m4 files, you need to always 
define preprocessor macros that are used for logical tests -- it is not 
sufficient to #define them or not.  Instead, always define them to 0 or 1 
(which would have made much of the original patch be valid).

Please update; thanks.


On Mar 2, 2014, at 10:41 PM,  wrote:

> Author: vasily (Vasily Philipov)
> Date: 2014-03-03 01:41:46 EST (Mon, 03 Mar 2014)
> New Revision: 30905
> URL: https://svn.open-mpi.org/trac/ompi/changeset/30905
> 
> Log:
> OPENIB BTL/CONNECT: warning fixes caused by r30875.
> 
> Text files modified: 
>   trunk/ompi/mca/btl/openib/configure.m4| 3 ++
>   
>   trunk/ompi/mca/btl/openib/connect/btl_openib_connect_rdmacm.c |52 
> 
>   2 files changed, 29 insertions(+), 26 deletions(-)
> 
> Modified: trunk/ompi/mca/btl/openib/configure.m4
> ==
> --- trunk/ompi/mca/btl/openib/configure.m4Sat Mar  1 22:48:56 2014
> (r30904)
> +++ trunk/ompi/mca/btl/openib/configure.m42014-03-03 01:41:46 EST (Mon, 
> 03 Mar 2014)  (r30905)
> @@ -102,6 +102,9 @@
> ],
> [ AC_MSG_RESULT([no])
>   AC_MSG_WARN([rsockets does not support keepalives. 
> librdmacm 1.0.18 or beyond is needed.])
> +],
> +[
> +  AC_MSG_WARN([cross compiling detected - disable IB 
> addressing support in RDMACM openib BTL.])
> ]
>   )
>   LDFLAGS="$LDFLAGS_save"
> 
> Modified: trunk/ompi/mca/btl/openib/connect/btl_openib_connect_rdmacm.c
> ==
> --- trunk/ompi/mca/btl/openib/connect/btl_openib_connect_rdmacm.c Sat Mar 
>  1 22:48:56 2014(r30904)
> +++ trunk/ompi/mca/btl/openib/connect/btl_openib_connect_rdmacm.c 
> 2014-03-03 01:41:46 EST (Mon, 03 Mar 2014)  (r30905)
> @@ -58,7 +58,7 @@
> #include "btl_openib_ip.h"
> #include "btl_openib_ini.h"
> 
> -#if BTL_OPENIB_RDMACM_IB_ADDR
> +#if defined(BTL_OPENIB_RDMACM_IB_ADDR)
> #include 
> #endif
> 
> @@ -89,7 +89,7 @@
> /* Dummy QP only used when we expect the connection to be
>rejected */
> struct ibv_cq *dummy_cq;
> -#if BTL_OPENIB_RDMACM_IB_ADDR
> +#if defined(BTL_OPENIB_RDMACM_IB_ADDR)
> union ibv_gid gid;
> uint64_t service_id;
> #else
> @@ -123,7 +123,7 @@
> typedef struct {
> int device_max_qp_rd_atom;
> int device_max_qp_init_rd_atom;
> -#if BTL_OPENIB_RDMACM_IB_ADDR
> +#if defined(BTL_OPENIB_RDMACM_IB_ADDR)
> uint8_t  gid[16];
> uint64_t service_id;
> #else
> @@ -161,7 +161,7 @@
> 
> typedef struct {
> uint32_t rem_index;
> -#if BTL_OPENIB_RDMACM_IB_ADDR
> +#if defined(BTL_OPENIB_RDMACM_IB_ADDR)
> uint64_t rem_port;
> #else
> uint16_t rem_port;
> @@ -233,7 +233,7 @@
> contents->endpoint = NULL;
> contents->openib_btl = NULL;
> contents->dummy_cq = NULL;
> -#if BTL_OPENIB_RDMACM_IB_ADDR
> +#if defined(BTL_OPENIB_RDMACM_IB_ADDR)
> contents->service_id = 0;
> #else
> contents->ipaddr = 0;
> @@ -355,7 +355,7 @@
>  */
> static mca_btl_openib_endpoint_t *rdmacm_find_endpoint(rdmacm_contents_t 
> *contents,
>struct rdma_cm_id *id,
> -#if BTL_OPENIB_RDMACM_IB_ADDR
> +#if defined(BTL_OPENIB_RDMACM_IB_ADDR)
>uint64_t rem_port)
> #else
>uint16_t rem_port)
> @@ -366,7 +366,7 @@
> opal_pointer_array_t *endpoints = contents->openib_btl->device->endpoints;
> 
> struct sockaddr *peeraddr = rdma_get_peer_addr(id);
> -#if BTL_OPENIB_RDMACM_IB_ADDR
> +#if defined(BTL_OPENIB_RDMACM_IB_ADDR)
> union ibv_gid *ep_gid, peer_gid;
> memcpy(peer_gid.raw, ((struct sockaddr_ib *) peeraddr)->sib_addr.sib_raw, 
> sizeof peer_gid);
> #else
> @@ -401,7 +401,7 @@
> #endif
> #endif
> 
> -#if BTL_OPENIB_RDMACM_IB_ADDR
> +#if defined(BTL_OPENIB_RDMACM_IB_ADDR)
> ep_gid = (union ibv_gid *) message->gid;
> if (ep_gid->global.interface_id == peer_gid.global.interface_id &&
>  ep_gid->global.subnet_prefix == peer_gid.global.subnet_prefix &&
> @@ -546,7 +546,7 @@
>  * node), then the process with the lower TCP port wins.
>  */
> static bool i_initiate(uint64_t local_port, uint64_t remote_port,
> -#if BTL_OPENIB_RDMACM_IB_ADDR
> +#if defined(BTL_OPENIB_RDMACM_IB_ADDR)
>union ibv_gid *local_gid, union ibv_gid *remote_gid)
> {
> #else
> @@ -558,7 +558,7 @@
> #endif
> #endif
> 
> -#if BTL_OPENIB_RDMACM_IB_ADDR
> +#if defined(BTL_OPENIB_RDMACM_IB_ADDR)
> if (local_gid->global.subnet_prefix < remote_gid->global.subnet_prefix ||
>

Re: [OMPI devel] Fix compiler warnings in FT code

2014-03-03 Thread Adrian Reber 
I removed a complete function because it was not used:

../../../../../orte/mca/sstore/stage/sstore_stage_component.c: At top level:
../../../../../orte/mca/sstore/stage/sstore_stage_component.c:77:12: warning: 
'sstore_stage_select' defined but not used [-Wunused-function]
 static int sstore_stage_select (void)

And grepping through the code it seems the compiler is right.

Should we keep the code and maybe just #ifdef it out.

On Mon, Mar 03, 2014 at 07:17:19AM -0600, Josh Hursey wrote:
> It looks like you removed a number of sstore stage MCA parameters. Did they
> move somewhere else? or do you have a different way to set those parameters?
> 
> Other than that it looks good to me.
> 
> 
> On Mon, Mar 3, 2014 at 5:29 AM, Adrian Reber  wrote:
> 
> > I have a simple patch which fixes the remaining compiler warnings when
> > running with '--with-ft':
> >
> >
> > https://lisas.de/git/?p=open-mpi.git;a=commitdiff;h=4dee703a0a2e64972b0c35b7693c11a09f1fbe5f
> >
> > Does anybody see any problems with this patch?
> >
> > Adrian
> > ___
> > devel mailing list
> > de...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] Fix compiler warnings in FT code

2014-03-03 Thread Josh Hursey 
It looks like you removed a number of sstore stage MCA parameters. Did they
move somewhere else? or do you have a different way to set those parameters?

Other than that it looks good to me.


On Mon, Mar 3, 2014 at 5:29 AM, Adrian Reber  wrote:

> I have a simple patch which fixes the remaining compiler warnings when
> running with '--with-ft':
>
>
> https://lisas.de/git/?p=open-mpi.git;a=commitdiff;h=4dee703a0a2e64972b0c35b7693c11a09f1fbe5f
>
> Does anybody see any problems with this patch?
>
> Adrian
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>



-- 
Joshua Hursey
Assistant Professor of Computer Science
University of Wisconsin-La Crosse
http://cs.uwlax.edu/~jjhursey

[OMPI devel] Fix compiler warnings in FT code

2014-03-03 Thread Adrian Reber 
I have a simple patch which fixes the remaining compiler warnings when
running with '--with-ft':

https://lisas.de/git/?p=open-mpi.git;a=commitdiff;h=4dee703a0a2e64972b0c35b7693c11a09f1fbe5f

Does anybody see any problems with this patch?

Adrian

Re: [OMPI devel] autoconf warnings: openib BTL

2014-03-03 Thread Vasily Filipov 
some additional explanation  - it could be a situation when AF_IB is 
defined in user space but kernel doesn't support it.


On 03-Mar-14 08:53, Vasily Filipov wrote:

Hi Jeff,
I've committed the fixes (r30905). It is a problem to detect 
kernel defines (such as AF_IB ), so we have to use AC_RUN_IFELSE macro.


Thanks,
Vasily.

On 27-Feb-14 17:09, Jeff Squyres (jsquyres) wrote:

I'm seeing this warning this morning:

-
configure.ac:1139: warning: AC_RUN_IFELSE called without default to 
allow cross c\

ompiling
../../lib/autoconf/general.m4:2748: AC_RUN_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:639: AS_IF is expanded from...
ompi/mca/btl/openib/configure.m4:37: MCA_ompi_btl_openib_CONFIG is 
expanded from.\

..
config/ompi_mca.m4:571: MCA_CONFIGURE_M4_CONFIG_COMPONENT is expanded 
from...

config/ompi_mca.m4:352: MCA_CONFIGURE_FRAMEWORK is expanded from...
config/ompi_mca.m4:252: MCA_CONFIGURE_PROJECT is expanded from...
config/ompi_mca.m4:39: OMPI_MCA is expanded from...
configure.ac:1139: the top level
-

Is it necessary to AC_RUN_IFELSE here?  Is AC_CHECK_DECLS not 
sufficient for some reason?


It strikes me that this test you currently have in configure.m4 
really should be a run-time test, and that all you need in 
configure.m4 should be an AC_CHECK_DECLS to see if AF_IB exists.

Re: [OMPI devel] autoconf warnings: openib BTL

2014-03-03 Thread Vasily Filipov 

Hi Jeff,
I've committed the fixes (r30905). It is a problem to detect kernel 
defines (such as AF_IB ), so we have to use AC_RUN_IFELSE macro.


Thanks,
Vasily.

On 27-Feb-14 17:09, Jeff Squyres (jsquyres) wrote:

I'm seeing this warning this morning:

-
configure.ac:1139: warning: AC_RUN_IFELSE called without default to allow cross 
c\
ompiling
../../lib/autoconf/general.m4:2748: AC_RUN_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:639: AS_IF is expanded from...
ompi/mca/btl/openib/configure.m4:37: MCA_ompi_btl_openib_CONFIG is expanded 
from.\
..
config/ompi_mca.m4:571: MCA_CONFIGURE_M4_CONFIG_COMPONENT is expanded from...
config/ompi_mca.m4:352: MCA_CONFIGURE_FRAMEWORK is expanded from...
config/ompi_mca.m4:252: MCA_CONFIGURE_PROJECT is expanded from...
config/ompi_mca.m4:39: OMPI_MCA is expanded from...
configure.ac:1139: the top level
-

Is it necessary to AC_RUN_IFELSE here?  Is AC_CHECK_DECLS not sufficient for 
some reason?

It strikes me that this test you currently have in configure.m4 really should 
be a run-time test, and that all you need in configure.m4 should be an 
AC_CHECK_DECLS to see if AF_IB exists.