Someone who understands the mpi debugging handles code:
The opal_progress_recursion_depth_counter and opal_progress_thread_counter
are both only used internally in opal_progress (for book keeping, but
never any decisions) and are declared in ompi_mpihandles_dll.c, but then
don't appear to be used. Is there a disadvantage to:
1) removing them from mpihandles_dll.c
or, if that breaks ABI,
2) Leaving them, but not doing the bookkeeping?
It's fairly heavyweight bookkeeping, so I agree with Nathan, I'd like to
remove it. But I'd like to remove it pre-1.7.4. Which means today.
On 12/18/13 4:40 PM, "Nathan Hjelm" <hjelmn_at_[hidden]> wrote:
>Opps, yeah. Meant 1.7.5. If people agree with this change I could
>possibly slip it in before Friday but that is unlikely.
>On Wed, Dec 18, 2013 at 03:32:36PM -0800, Ralph Castain wrote:
>> Ummmm....1.7.4 is leaving the station on Fri, Nathan, so next Tues =>
>>will have to go into 1.7.5
>> On Dec 18, 2013, at 3:23 PM, Nathan Hjelm <hjelmn_at_[hidden]> wrote:
>> > What: Remove the opal_progress_recursion_depth_counter from
>> > opal_progress.
>> > Why: This counter adds two atomic adds to the critical path when
>> > OPAL_HAVE_THREADS is set (which is the case for most builds). I
>> > through ompi, orte, and opal to find where this value was being used
>> > did not find anything either inside or outside opal_progress.
>> > When: I want this change to go into 1.7.4 (if possible) so setting a
>> > quick timeout for next Tuesday.
>> > Let me know if there is a good reason to keep this counter and it will
>> > be spared.
>> > -Nathan Hjelm
>> > HPC-5, LANL
>> > _______________________________________________
>> > devel mailing list
>> > devel_at_[hidden]
>> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> devel mailing list
Brian W. Barrett
Scalable System Software Group
Sandia National Laboratories