On Jul 29, 2008, at 8:43 AM, Ralph Castain wrote:
Lenny's point is true - except for the danger of setting that mca
param and its possible impact on ORTE daemons+mpirun - see other
note in that regard. However, it would only be useful if the same
user was doing it.
I believe Tim was conce
Lenny's point is true - except for the danger of setting that mca
param and its possible impact on ORTE daemons+mpirun - see other note
in that regard. However, it would only be useful if the same user was
doing it.
I believe Tim was concerned about the case where two users are sharing
no
for two separate runs we can use slot_list parameter (
opal_paffinity_base_slot_list ) to have paffinity
1: mpirun -mca opal_paffinity_base_slot_list "0-1"
2 :mpirun -mca opal_paffinity_base_slot_list "2-3"
On 7/28/08, Ralph Castain wrote:
>
> Actually, this is true today regardless of this cha
Actually, this is true today regardless of this change. If two
separate mpirun invocations share a node and attempt to use paffinity,
they will conflict with each other. The problem isn't caused by the
hostfile sub-allocation. The problem is that the two mpiruns have no
knowledge of each ot
My only concern is how will this interact with PLPA.
Say two Open MPI jobs each use "half" the cores (slots) on a
particular node... how would they be able to bind themselves to
a disjoint set of cores? I'm not asking you to solve this Ralph, I'm
just pointing it out so we can maybe warn users th
Per an earlier telecon, I have modified the hostfile behavior slightly
to allow hostfiles to subdivide allocations.
Briefly: given an allocation, we allow users to specify --hostfile on
a per-app_context basis. In this mode, the hostfile info is used to
filter the nodes that will be used fo
