[Mpi-forum] Question about MPI_Info set on communicators

Jeff Hammond jeff.science at gmail.com
Tue Feb 16 13:15:43 CST 2016


On Tue, Feb 16, 2016 at 6:50 AM, Jeff Squyres (jsquyres) <jsquyres at cisco.com
> wrote:

> Jim --
>
> Based on your answer, I'm now a bit confused.  I now need to back up from
> my original question and clarify what MPI_COMM_INFO_GET is supposed to
> return in this scenario:
>
> -----
> MPI_Info_set(myinfo, "use_shared_memory", "yes");
> MPI_Comm_set_info(comm, my info);
> // MPI implementation recognizes the "use_shared_memory" hint, but is
> // unable to use shared memory with this communicator
> MPI_Comm_get_info(comm, myinfo_returned);
> -----
>
> What value is in myinfo_returned for use_shared_memory?
>
> MPI 3.1 6.4.4 p250 says:
>
> "MPI_COMM_GET_INFO returns a new info object containing the hints of the
> communicator associated with comm. The current setting of all hints
> actually used by the system related to this communicator is returned in
> info_used."
>
> "...all hints actually used by the system..." is actually a bit ambiguous.
>
> In this case, "use_shared_memory" is *recognized* by the MPI
> implementation.  But it wasn't able to be *used* (e.g., because no shared
> memory was available).  So is the value in info_used supposed to be:
>
>
How does it know how much shared memory is required?  I don't see any
reason for MPI_Comm_set_info to fail on account of lack of shared memory.
If zero bytes of shared memory are available, how does MPI_Comm_set_info
know that this is not enough when the user actually needs?


> 1. The user's requested hint (i.e., "yes"), or
>

I'm changing my answer to this one, in this case.  For MPI_Alloc_mem and
MPI_Win_allocate(_shared), my answer will be different.

The only reasonable behavior is for MPI_Comm_set_info to succeed and set
"use_shared_memory"="yes".  Subsequent operations may behave differently
depending on how much shared memory is available.  I would expect the user
to probe that using MPI_T.

Jeff


> 2. What MPI is actually using (i.e., "no"), or
> 3. Since this hint wasn't "used" by the system, then the
> "use_shared_memory" key shouldn't be returned in info_used
>
> ?
>
> Indeed, one could make the argument that MPI_COMM_GET_INFO is supposed to
> return exactly the value(s) that the user requested (if it is *recognized*
> by the implementation), and MPI_T pvars and/or cvars should be queried to
> obtain the values indicating what the implementation chose to do with those
> hints.
>
> Thoughts?
>
>
>
> On February 15, 2016 at 8:25:44 PM, Jim Dinan (james.dinan at gmail.com)
> wrote:
> > "Same" should mean that these call sequences produce the same newcomm,
> > right?
> >
> > MPI_Comm_get_info(comm, myinfo_returned);
> > MPI_Comm_dup_with_info(comm, &newcomm, myinfo_returned);
> >
> > and
> >
> > MPI_Comm_dup(comm, &newcomm);
> >
> > I think this is an argument for "no".
> >
> > I'm not sure if the question is asking whether the MPI implementation can
> > change communicator info values dynamically. I'm not sure the spec
> > actually addresses that possibility. If this is allowed, newcomm would
> > still only get "yes" if the implementation had also toggled the info key
> on
> > the parent communicator.
> >
> > ~Jim.
> >
> > On Mon, Feb 15, 2016 at 5:34 PM, Jeff Squyres (jsquyres) > > wrote:
> >
> > > This question has come up in the Open MPI community:
> > >
> > > -----
> > > MPI_Info_set(myinfo, "use_shared_memory", "yes");
> > > MPI_Comm_set_info(comm, myinfo);
> > > MPI_Comm_get_info(comm, myinfo_returned);
> > > // Assume here that there was not enough shared memory available to use
> > > shared-memory for
> > > // communication on this comm, so MPI_Info_get() tells us that
> > > use_shared_memory is "no".
> > >
> > > // ...time passes, and now assume there is more shared-memory available
> > > MPI_Comm_dup_with_info(comm, &newcom);
> > > MPI_comm_get_info(newcom, myinfo_returned);
> > > -----
> > >
> > > Should newcom have "use_shared_memory" set to "yes" or "no"?
> > >
> > > Arguments for "yes":
> > > - the user originally asked for "yes"
> > > - now there is shared memory available
> > >
> > > Arguments for "no":
> > > - the current value for "used_shared_memory" on the parent
> communicator is
> > > "no"
> > >
> > > Which should it be?
> > >
> > > MPI-3.1 6.4.2 p238 says:
> > >
> > > "...Returns in newcomer a new communicator with the same group or
> groups,
> > > same topology, same info hints, any copied cached information, but a
> new
> > > context (see Section 6.7.1)."
> > >
> > > So the specific question here is: what exactly does "Same info hints"
> > > mean? The user-specific hint, or the current value of the hint?
> > >
> > > --
> > > Jeff Squyres
> > > jsquyres at cisco.com
> > > For corporate legal information go to:
> > > http://www.cisco.com/web/about/doing_business/legal/cri/
> > > _______________________________________________
> > > mpi-forum mailing list
> > > mpi-forum at lists.mpi-forum.org
> > > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
> > _______________________________________________
> > mpi-forum mailing list
> > mpi-forum at lists.mpi-forum.org
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>
> --
> Jeff Squyres
> jsquyres at cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
> _______________________________________________
> mpi-forum mailing list
> mpi-forum at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>



-- 
Jeff Hammond
jeff.science at gmail.com
http://jeffhammond.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20160216/40a7a9b8/attachment-0001.html>


More information about the mpi-forum mailing list