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 Gouaillardet > <[email protected]> wrote: > > 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 <[email protected] > <mailto:[email protected]>> wrote: > 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 called “comm_spawn”. The code for recycling those has gone a > tad stale, but it wouldn’t be hard to recover it. I doubt someone will call > comm_spawn more than 2^15 times without at least one of those completing so > we can reuse the jobid, and so it should be safe to take the upper bit of > that field. > > Frankly, I thought the second option was what Nathan had intended, so I’m > surprised to see us masking at the 64-bit level. This touches the mpirun part > of the jobid (the upper 16-bits), which is a hash based on the hostname and > OS pid. Stripping a bit from that is risky and I definitely wouldn’t advise > it. > > >> On Feb 5, 2016, at 7:48 PM, Gilles Gouaillardet >> <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: >> >> 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 <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: >> 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)" <[email protected] <>> >> wrote: >> On Feb 5, 2016, at 9:26 AM, Gilles Gouaillardet >> <[email protected] <>> wrote: >> > >> > static inline opal_process_name_t ompi_proc_sentinel_to_name (intptr_t >> > sentinel) >> > { >> > sentinel >>= 1; >> > sentinel &= 0x7FFFFFFFFFFFFFFF; >> > return *((opal_process_name_t *) &sentinel); >> > } >> >> I don't have much of an opinion on any of the other stuff here, but I note >> that this is unsafe. I know we don't really care about non-64 bit these >> days, but we shouldn't be knowingly breaking it. Instead of ANDing with a >> fixed constant, shouldn't it be something like: >> >> intptr_t mask = ~1 >> 1; >> sentinel &= mask; >> >> -- >> Jeff Squyres >> [email protected] <> >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> <http://www.cisco.com/web/about/doing_business/legal/cri/> >> >> _______________________________________________ >> devel mailing list >> [email protected] <> >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> <http://www.open-mpi.org/mailman/listinfo.cgi/devel> >> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2016/02/18557.php >> <http://www.open-mpi.org/community/lists/devel/2016/02/18557.php> >> _______________________________________________ >> devel mailing list >> [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');> >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> <http://www.open-mpi.org/mailman/listinfo.cgi/devel> >> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2016/02/18563.php >> <http://www.open-mpi.org/community/lists/devel/2016/02/18563.php> > _______________________________________________ > devel mailing list > [email protected] > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2016/02/18565.php
