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. Brian On 12/18/13 4:40 PM, "Nathan Hjelm" <hje...@lanl.gov> 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 <hje...@lanl.gov> 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 >>grepped >> > through ompi, orte, and opal to find where this value was being used >>and >> > 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 >> > de...@open-mpi.org >> > http://www.open-mpi.org/mailman/listinfo.cgi/devel >> >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > -- Brian W. Barrett Scalable System Software Group Sandia National Laboratories