Re: [OMPI devel] add_procs

[George Bosilca]

This functionality has as many chances to be called as any MPI 2  
dynamics MPI functions. Every time the MPI universe is expanded, once  
the modex of the new processes is known, add procs is called in order  
to allow the PML and BTL to update their local view of the MPI universe.


The code is robust and well tested by a lot of people (please check  
the maling list about spawn problems). Unfortunately, as you noticed,  
the current incarnation of sm doesn't support spawn. If there is any  
changes to be made, adding support for spawn in sm is the direction in  
which we should look, as sm is the only BTL today that doesn't support  
dynamic processes.


  george.

On Feb 5, 2009, at 14:41 , Eugene Loh wrote:

BTLs have "add_procs" functions.  E.g., my own parochial interests  
are with the sm BTL and there is a mca_btl_sm_add_procs() function.   
I'm trying to get a feel for how likely it is that this function  
would be called more than once.  There is code in there to support  
the case where it's called multiple times:  e.g., don't just call it  
once during MPI_Init, but again during program execution to add more  
processes.


Maybe we can do this the "multiple choice" method:

A) That code is in there for standard purposes (dynamically added  
processes or something?) and is robust and routinely tested.


B) That code was in there because we had hoped to support this stuff  
someday, but I'm not sure if it works.  It's not really tested and  
rarely used by our users.  We should clean it up sometime so that  
we're sure it's doing what it should.


C) That code was a fantasy we had when we first started coding this  
stuff, and for sure there is no prayer of that stuff working  
properly today or any time in the foreseeable future without major  
work.  Come to think of it, we'd be doing ourselves a service by  
ripping all that stuff out.

___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] add_procs

[Ralph Castain]

I would only add that we should be certain that the code is -not-  
called more than once as this could cause problems. We don't currently  
have a way for dynamically spawned procs to share memory with their  
parents - if that code does get called, I would worry that it hadn't  
been tested and could cause memory issues.



On Feb 5, 2009, at 1:26 PM, Richard Graham wrote:

I would leave the code alone.  The intent was for (A), but it is not  
used
for that.  It is not in the performance critical region, works  
correctly as
we use it today, and putting it back later on would be a hassle not  
needed.


Rich


On 2/5/09 2:41 PM, "Eugene Loh"  wrote:

BTLs have "add_procs" functions.  E.g., my own parochial interests  
are

with the sm BTL and there is a mca_btl_sm_add_procs() function.  I'm
trying to get a feel for how likely it is that this function would be
called more than once.  There is code in there to support the case  
where

it's called multiple times:  e.g., don't just call it once during
MPI_Init, but again during program execution to add more processes.

Maybe we can do this the "multiple choice" method:

A) That code is in there for standard purposes (dynamically added
processes or something?) and is robust and routinely tested.

B) That code was in there because we had hoped to support this stuff
someday, but I'm not sure if it works.  It's not really tested and
rarely used by our users.  We should clean it up sometime so that  
we're

sure it's doing what it should.

C) That code was a fantasy we had when we first started coding this
stuff, and for sure there is no prayer of that stuff working properly
today or any time in the foreseeable future without major work.   
Come to
think of it, we'd be doing ourselves a service by ripping all that  
stuff

out.
___
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] add_procs

[Richard Graham]

I would leave the code alone.  The intent was for (A), but it is not used
for that.  It is not in the performance critical region, works correctly as
we use it today, and putting it back later on would be a hassle not needed.

Rich


On 2/5/09 2:41 PM, "Eugene Loh"  wrote:

> BTLs have "add_procs" functions.  E.g., my own parochial interests are
> with the sm BTL and there is a mca_btl_sm_add_procs() function.  I'm
> trying to get a feel for how likely it is that this function would be
> called more than once.  There is code in there to support the case where
> it's called multiple times:  e.g., don't just call it once during
> MPI_Init, but again during program execution to add more processes.
> 
> Maybe we can do this the "multiple choice" method:
> 
> A) That code is in there for standard purposes (dynamically added
> processes or something?) and is robust and routinely tested.
> 
> B) That code was in there because we had hoped to support this stuff
> someday, but I'm not sure if it works.  It's not really tested and
> rarely used by our users.  We should clean it up sometime so that we're
> sure it's doing what it should.
> 
> C) That code was a fantasy we had when we first started coding this
> stuff, and for sure there is no prayer of that stuff working properly
> today or any time in the foreseeable future without major work.  Come to
> think of it, we'd be doing ourselves a service by ripping all that stuff
> out.
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

[OMPI devel] add_procs

[Eugene Loh]

BTLs have "add_procs" functions.  E.g., my own parochial interests are 
with the sm BTL and there is a mca_btl_sm_add_procs() function.  I'm 
trying to get a feel for how likely it is that this function would be 
called more than once.  There is code in there to support the case where 
it's called multiple times:  e.g., don't just call it once during 
MPI_Init, but again during program execution to add more processes.


Maybe we can do this the "multiple choice" method:

A) That code is in there for standard purposes (dynamically added 
processes or something?) and is robust and routinely tested.


B) That code was in there because we had hoped to support this stuff 
someday, but I'm not sure if it works.  It's not really tested and 
rarely used by our users.  We should clean it up sometime so that we're 
sure it's doing what it should.


C) That code was a fantasy we had when we first started coding this 
stuff, and for sure there is no prayer of that stuff working properly 
today or any time in the foreseeable future without major work.  Come to 
think of it, we'd be doing ourselves a service by ripping all that stuff 
out.