As Rich stated, the original design of the SM BTL included [some]
support for dynamic processes. Over the years, by lack of interest and
man-power this support was more or less dropped. Some pieces of the
code were removed or disabled, but apparently not everything.
However, lately the interest for dynamic support over SM was revived
at UTK. We are currently working on a new version of the SM BTL that
will support MPI-2 dynamics over SM. Therefore, I think the safest
approach right now is to keep the code and back the default value to
zero (and eventually make the corresponding MCA parameter hidden and/
or read-only).
george.
On Dec 23, 2008, at 13:06 , Eugene Loh wrote:
Well, and we only allocate extra FIFOs, but we don't initialize
them. Also, the eager free list is initially set up to grow with
the number of connections (some attempt to avoid deadlock, I
imagine), but this initial eager free list size doesn't account for
the extra procs either.
So, shall we remove that code and associated MCA parameters? Or, as
Lenny suggests, just back the default down to 0 and leave the code in?
Richard Graham wrote:
Not needed now. Since we did not want to deal with trying to grow
the
shared memory file after it's allocation, with all the required
synchronization, we allocated extra memory up front - for dynamic
process
control. Since this has never been enabled, we really don't need
this extra
memory.
On 12/22/08 11:47 AM, "Eugene Loh" <eugene....@sun.com> wrote:
Why does the sm BTL allocate "extra procs"?
E.g.,
https://svn.open-mpi.org/trac/ompi/browser/branches/v1.3/ompi/mca/btl/sm/btl_s
m.c?version=19785#L403
In particular:
*) sm_max_procs is -1 (so there is no max)
*) sm_sm_extra_procs (sic, this is the ompi_info name) is 2
So, if there are n procs on the node, it allocates FIFOs for n*(n+2)
connections. Why?
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
