I see your point, but I don't know how to make that happen. The problem is that spawn really should fail under certain conditions because you asked us to do something we couldn't do - i.e., you asked that we launch and bind more processes then we could. Increasing the number of available resources will always change the situation and make it more likely spawn will succeed.
You can still trigger the behavior by individually setting the oversubscribe property in the --may-by option - instead of giving "--oversubscribe", just use "--map-by :oversubscribe". This will allow oversubscription but not overload, and you'll be back to the original scenario. On Tue, Jun 24, 2014 at 10:03 PM, Gilles Gouaillardet < gilles.gouaillar...@iferc.org> wrote: > Hi Ralph, > > On 2014/06/25 2:51, Ralph Castain wrote: > > Had a chance to review this with folks here, and we think that having > > oversubscribe automatically set overload makes some sense. However, we do > > want to retain the ability to separately specify oversubscribe and > overload > > as well since these two terms don't mean quite the same thing. > > > > Our proposal, therefore, is to have the --oversubscribe flag set both the > > --map-by :oversubscribe and --bind-to :overload-allowed properties. If > > someone specifies both the --oversubscribe flag and a conflicting > directive > > for one or both of the individual properties, then we'll error out with a > > "bozo" message. > i fully agree. > > The use-cases you describe are (minus the crash) correct as the warning > > only is emitted when you are overloaded (i.e., trying to bind to more > cpus > > than you have). So you won't get any warning when running on three nodes > as > > you have enough cpus for all the procs, etc. > > > > I'll investigate the crash once I get home and have access to a cluster > > again. The problem likely has to do with not properly responding to the > > failure to spawn. > humm > > because you already made the change described above(r32072), the crash > does not occur any more. > > about the crash, i see things the other way around : spawn should have > not failed. > /* or spawn should have failed when running on a single node, at least > for the sake of consistency */ > > but like i said, it works now, so it might be just pedantic to point a > bug that is still here but that cannot be triggered ... > > Cheers, > > Gilles > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2014/06/15053.php >
