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/
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
>> shared memory file after it's allocation, with all the required
>> synchronization, we allocated extra memory up front - for dynamic
>> control. Since this has never been enabled, we really don't need
>> this extra
>> On 12/22/08 11:47 AM, "Eugene Loh" <Eugene.Loh_at_[hidden]> wrote:
>>> Why does the sm BTL allocate "extra procs"?
>>> 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