On Thu, Jul 18, 2013 at 07:53:35AM -0700, Ralph Castain wrote:
> 
> On Jul 18, 2013, at 7:05 AM, David Goodell (dgoodell) <dgood...@cisco.com> 
> wrote:
> 
> > On Jul 18, 2013, at 8:06 AM, Ralph Castain <r...@open-mpi.org> wrote:
> > 
> >> That's a good point, and a bad behavior. IIRC, it results from the MPI 
> >> Forum's adoption of the MPI-T requirement that stipulates we must allow 
> >> access to all control and performance variables at startup so they can be 
> >> externally seen/manipulated.
> > 
> > Minor nit: MPI_T does not require this.  However, it does recommend that 
> > you offer users access to as many variables as possible as early as 
> > reasonably possible for the convenience and control of the user.
> > 
> > If an implementation chooses to offer 5% of the possible 
> > control/performance variables to the user just before MPI_Finalize, that's 
> > still a valid MPI_T implementation.  But it may not be a very useful one...
> 
> The problem here is one of use vs startup performance. George is quite 
> correct with his concerns - this behavior would have been a serious problem 
> for RoadRunner, for example, where we had a small IO channel feeding a lot of 
> nodes. It will definitely become an issue at exascale where IO bandwidth and 
> memory will be at a premium.
> 
> This is especially troubling when you consider how few people will ever use 
> this capability. Perhaps we should offer a switch that says "I want access to 
> MPI-T" so that the rest of the world isn't hammered by this kind of behavior?

This was discussed in depth before the MCA rewrite came into the trunk. There 
are only two cases where we load and register all the available components: 
ompi_info, and MPI_T_init_thread(). The normal MPI case does not have this 
behavior and instead loads only the requested components.

-Nathan

Reply via email to