Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] [OMPI svn] svn:open-mpi r31302 - in trunk: opal/mca/base orte/tools/orterun
From: Ralph Castain (rhc_at_[hidden])
Date: 2014-04-03 12:41:09


Maybe?? It would help avoid the unexpected behavior problem, but may ultimately be too unwieldy for widespread adoption. Still, an option to ponder.

On Apr 3, 2014, at 9:27 AM, Kenneth A. Lloyd <kenneth.lloyd_at_[hidden]> wrote:

> Would you consider a user-defined process language library outside of
> OpenMPI? Process functors could be defined by compositions in this external
> area, and maintenance of the language simply the user's responsibility?
>
> -----Original Message-----
> From: devel [mailto:devel-bounces_at_[hidden]] On Behalf Of Ralph Castain
> Sent: Thursday, April 03, 2014 8:17 AM
> To: Open MPI Developers
> Subject: Re: [OMPI devel] [OMPI svn] svn:open-mpi r31302 - in trunk:
> opal/mca/base orte/tools/orterun
>
> I can see the potential utility, but I do have concerns about how to make it
> work without causing a lot of user problems:
>
> * as currently implemented, it only affects procs launched via mpirun. This
> seems odd - if the user does a direct launch, they would get totally
> different behavior? Shouldn't the registering and parsing of this MCA param
> follow our usual procedure and be done by the application itself instead of
> by orterun?
>
> * Imagine someone has entered this MCA param into the default MCA param
> file, and that it includes "foo=car" in it. Now the user sets "foo=baz" in
> their environment. How many hours will the user spend tearing out his/her
> hair trying to understand why the application behavior isn't as expected
> before they finally realize that the default MCA param file is messing with
> their non-OMPI envars? Once they finally do figure it out, how do they
> "zero" that MCA param so it isn't processed? We don't have a mechanism for
> overriding a value with "NULL" - doesn't this option require one?
>
> * again, someone puts an entry in the default MCA param file that includes
> "foo=car". The user executes mpirun with "-x foo=baz", which is perfectly
> legitimate. What is the precedence rule we use to determine the value of
> foo? If we consolidate the two options (as you suggest), then this would be
> alleviated - but one is an MCA param and the other a non-MCA cmd-line
> option, so we would have to break backward compatibility to resolve it
> (which isn't impossible - just worth a discussion).
>
> * assume an entry in the MCA param file that includes multiple envars, one
> of which is "foo=car". If the user then puts "-mca env_list foo=baz" on
> their cmd line, do we delete all the other envars in the original entry and
> only do the new one? Or would someone expect that only the new one would be
> modified or added, but the others would remain?
>
> Hence I think this requires some discussion at next week's call. Remember,
> by policy, we don't forward non-MCA envars - but now we are forcibly setting
> them only in the app procs. Strikes me as a major change in behavior, and
> I'm not sure it won't cause more trouble than it solves.
>
>
> On Apr 3, 2014, at 1:01 AM, Shamis, Pavel <shamisp_at_[hidden]> wrote:
>
>>
>>> mca param file treats any key=val as mca parameter only.
>>> In order to add parser support for something that is not mca param, will
> require change file syntax and it will look bad, i.e.:
>>>
>>> mca btl = sm,self,openib
>>> env DISPLAY = console:0
>>>
>>> I think the current implementation is less intrusive and re-uses existing
> infra in the most elegant way.
>>> The param file syntax change is too big effort to justify this feature
> (IMHO) which can be provided with existing infra w/o breaking anything.
>>
>>
>> IMHO this is a useful parameter option to have. If we may consolidate
>> these two parameters (-x and the new one) into single one, it might be
> even more helpful.
>>
>> Best,
>> Pasha.
>> _______________________________________________
>> devel mailing list
>> devel_at_[hidden]
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post:
>> http://www.open-mpi.org/community/lists/devel/2014/04/14452.php
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/04/14453.php
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2014.0.4355 / Virus Database: 3722/7293 - Release Date: 04/03/14
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: http://www.open-mpi.org/community/lists/devel/2014/04/14454.php