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 <r...@open-mpi.org> 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 <
> gilles.gouaillar...@gmail.com
> <javascript:_e(%7B%7D,'cvml','gilles.gouaillar...@gmail.com');>> 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 <bosi...@icl.utk.edu
> <javascript:_e(%7B%7D,'cvml','bosi...@icl.utk.edu');>> 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)" <jsquy...@cisco.com>
>> wrote:
>>
>>> On Feb 5, 2016, at 9:26 AM, Gilles Gouaillardet <
>>> gilles.gouaillar...@gmail.com> 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
>>> jsquy...@cisco.com
>>> For corporate legal information go to:
>>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>>
>>> _______________________________________________
>>> 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/2016/02/18557.php
>>>
>> _______________________________________________
> devel mailing list
> de...@open-mpi.org <javascript:_e(%7B%7D,'cvml','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/2016/02/18563.php
>
>
>
