Re: [OMPI devel] ompi_procs_cutoff, jobid and vpid

Folks, i made PR #1345 https://github.com/open-mpi/ompi/pull/1345 i will run some more extensive tests on Monday. Cheers, Gilles On Sat, Feb 6, 2016 at 1:37 PM, Ralph Castain wrote: > FWIW: there are macros in orte/util/name_fns.h that will extract the > individual jobid

Re: [OMPI devel] ompi_procs_cutoff, jobid and vpid

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

Re: [OMPI devel] ompi_procs_cutoff, jobid and vpid

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

Re: [OMPI devel] ompi_procs_cutoff, jobid and vpid

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

Re: [OMPI devel] ompi_procs_cutoff, jobid and vpid

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

Re: [OMPI devel] ompi_procs_cutoff, jobid and vpid

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: >

Re: [OMPI devel] ompi_procs_cutoff, jobid and vpid

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

Re: [OMPI devel] ompi_procs_cutoff, jobid and vpid

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,

Re: [OMPI devel] ompi_procs_cutoff, jobid and vpid

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 *) ); > } I don't have much

[OMPI devel] ompi_procs_cutoff, jobid and vpid

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