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 <r...@open-mpi.org> wrote:
> 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
> <gilles.gouaillar...@gmail.com> 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 <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> 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> 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
>> 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
>>
>>
> _______________________________________________
> 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/18565.php
>
>
>
> _______________________________________________
> 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/18566.php
