FWIW: there are macros in orte/util/name_fns.h that will extract the individual
jobid fields, and there is another macro for reassembling the jobid from the
two pieces. If you use those, we’ll avoid any issues with future modifications
to the fields.
> On Feb 5, 2016, at 8:17 PM, Gilles Gouail
Thanks Ralph,
I will implement the second option.
conversion from sentinel to process name will require a few extra steps,
but that should not be in the critical path.
Cheers,
Gilles
On Saturday, February 6, 2016, Ralph Castain wrote:
> There are two potential places you could use:
>
> * the
There are two potential places you could use:
* the vpid itself is 32-bits in size - we are quite some years away from
needing all of them, so taking the upper-most bit for this purpose should be
okay
* the lower 16-bits of the jobid is the local jobid - i.e., the number of times
someone calle
Thanks George,
I will definitely try that !
back to the initial question, has someone any thoughts on which bit(s) we
can lose when using cutoff ?
Cheers,
Gilles
On Saturday, February 6, 2016, George Bosilca wrote:
> In addition shouldn't we use uintptr_t instead of the intptr_t to cope
> wi
In addition shouldn't we use uintptr_t instead of the intptr_t to cope with
the MSB during the shifting operations?
George
On Feb 5, 2016 10:08 AM, "Jeff Squyres (jsquyres)"
wrote:
> On Feb 5, 2016, at 9:26 AM, Gilles Gouaillardet <
> gilles.gouaillar...@gmail.com> wrote:
> >
> > static inline
FWIW: we do have a macro that safely returns the either field of the jobid,
whether in 32 or 64 bit environments. Is there some reason not to just use
those?
> On Feb 5, 2016, at 3:58 PM, Gilles Gouaillardet
> wrote:
>
> Jeff,
>
> first, cutoff currently assumes sizeof(intptr_t) ==
> sizeof
Jeff,
first, cutoff currently assumes sizeof(intptr_t) ==
sizeof(opal_process_name_t)
I will double check cutoff is automatically disabled or cannot be set on
32bits arch
iirc, I used an explicit unsigned long because the MSB is not cleared when
right shifting
Cheers,
Gilles
On Saturday, Febru
I’m pretty sure you can by simply enclosing the entire launch proxy command in
quotes, but I can take a look a little later today
> On Feb 5, 2016, at 7:17 AM, Justin Cinkelj wrote:
>
> I'm starting mpi program via --launch-proxy, and would like to pass some
> additional parameters to it. But
I'm starting mpi program via --launch-proxy, and would like to pass some
additional parameters to it. But I'm not able to figure out how to do
that (or if it is possible at all). Attempts to use environ failed:
OMPI_VAR1=aa mpirun program
mpirun -x VAR2=bb program
The program will get set OMPI_
On Feb 5, 2016, at 9:26 AM, Gilles Gouaillardet
wrote:
>
> static inline opal_process_name_t ompi_proc_sentinel_to_name (intptr_t
> sentinel)
> {
> sentinel >>= 1;
> sentinel &= 0x7FFF;
> return *((opal_process_name_t *) &sentinel);
> }
I don't have much of an opinion on any of
Folks,
i was unable to start a simple MPI job using the TCP btl on an
heterogeneous cluster and using --mca mpi_procs_cutoff 0.
The root cause was the most significant bit of the jobid was set on
some nodes but not on others.
This is what we have :
from opal/dss/dss_types.h
typedef uint32_t opa
11 matches
Mail list logo
