[mpiwg-p2p] Fwd: MPI P2P "messages may overtake" assertion

Tue Dec 15 09:45:47 CST 2015

It may be hard for tools or existing analysis techniques to provide
assistance to users when this mode is selected.  However, there is adequate
support through the MPI interface to detect when this mode has been
selected and restrict the tool's behavior -- i.e. a tool may have to ignore
traffic on communicators where this info key is active.  As Jeff pointed
out, tools can even prevent the application from providing this info key to
the library.

I don't really see any necessary fix to the proposal.  We could add an
advice to users to remind them that they should ensure tools are compatible
with the info keys.  And the reverse advice to tools writers that they
should check info keys for compatibility.

 ~Jim.

On Mon, Dec 14, 2015 at 10:59 AM, Daniel Holmes <dholmes at epcc.ed.ac.uk>
wrote:

> Hi Jeff,
>
> ... tools can just intercept the info operations and strip this key if
> they can't support it.
>
> Agreed: this should have been response 4 on my list (Markus and I
> discussed that option too).
>
> Cheers,
> Dan.
>
>
> On 14/12/2015 15:54, Jeff Hammond wrote:
>
> Remember that one of the use cases of allow_overtaking is applications
> that have exact matching, in which case allow_overtaking is a way of
> turning off a feature that isn't used, in order to get a high-performing
> message queue implementation.  In the exact matching case, tools will have
> no problem matching up sends and recvs.
>
> If tools cannot handle MPI_THREAD_MULTIPLE already, then I don't really
> care if they can't support this assertion either.
>
> And in any case, such tools can just intercept the info operations and
> strip this key if they can't support it.
>
> Jeff
>
> On Mon, Dec 14, 2015 at 7:44 AM, Daniel Holmes <dholmes at epcc.ed.ac.uk>
> wrote:
>
>> Hi all,
>>
>> Markus has reminded me that we discussed the effect of the
>> mpi_assert_allow_overtaking assertion on tools (see below).
>>
>> The basic problem is that message matching would be non-deterministic and
>> it would be impossible for a tool to show the user which receive operation
>> satisfied which send operation without internally using some sort of
>> sequence number for each send/receive operation. As Markus mentions, this
>> is a similar problem to the MPI_THREAD_MULTIPLE "logically concurrent"
>> issue, with which tools already struggle.
>>
>> My responses were:
>> 1) the user asked for this behaviour so the tool could simply gracefully
>> give up the linking function and just state the information it knows
>> 2) the tool could hook all send and receive operations and piggy-back a
>> sequence number into the message header
>> 3) the tool could hook all send and receive operations and serialise them
>> to prevent overtaking
>> I don't know the viability/acceptability of any of these approaches.
>>
>> Preferably before the formal reading at the next face-to-face meeting, we
>> should discuss the possibility that this assertion will disrupt tools and
>> ascertain if we can/want to do anything to mitigate that disruption.
>>
>> Cheers,
>> Dan.
>>
>> -------- Forwarded Message -------- Subject: MPI P2P "messages may
>> overtake" assertion Date: Mon, 14 Dec 2015 16:24:44 +0100 From: Markus
>> Geimer <m.geimer at fz-juelich.de> <m.geimer at fz-juelich.de> To:
>> dholmes at epcc.ed.ac.uk CC: Marc-André Hermanns
>> <m.a.hermanns at fz-juelich.de> <m.a.hermanns at fz-juelich.de>
>>
>> Hi Daniel,
>>
>> Do you remember our conversation after the MPI BoF at SC'15 about the
>> proposed "messages may overtake" assertion and that it may cause severe
>> problems for tools, as correct message matching is very important for
>> many of them?  In fact, the issue here is similar to properly supporting
>> MPI_THREAD_MULTIPLE, which most tools don't do either right now...
>>
>> Meanwhile I talked to Marc-Andre Hermanns from the Tools WG -- which
>> kick-started a discussion on this end.  But I guess this topic also
>> requires some involvement of the P2P WG.  For example, it would be good
>> if you could summarize the ideas you had in mind how tools could handle
>> this assertion. Thanks!
>>
>> That said, I don't think there is any urgency for discussions, as
>> people are slowly leaving for the Christmas break (e.g., I'm already
>> out of office).  But we should definitely follow up on this early next
>> year.
>>
>> Merry Christmas,
>> Markus
>>
>> --
>> Dr. Markus Geimer
>> Juelich Supercomputing Centre
>> Institute for Advanced Simulation
>> Forschungszentrum Juelich GmbH
>> 52425 Juelich, Germany
>>
>> Phone:  +49-2461-61-1773
>> Fax:    +49-2461-61-6656
>> E-Mail: m.geimer at fz-juelich.de
>> WWW:    http://www.fz-juelich.de/jsc
>>
>>
>> ------------------------------------------------------------------------------------------------
>> ------------------------------------------------------------------------------------------------
>> Forschungszentrum Juelich GmbH
>> 52425 Juelich
>> Sitz der Gesellschaft: Juelich
>> Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
>> Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
>> Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender),
>> Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
>> Prof. Dr. Sebastian M. Schmidt
>> ------------------------------------------------------------------------------------------------
>> ------------------------------------------------------------------------------------------------
>>
>>
>>
>>
>> --
>> Dan Holmes
>> Applications Consultant in HPC Research
>> EPCC, The University of Edinburgh
>> James Clerk Maxwell Building
>> The Kings Buildings
>> Peter Guthrie Tait Road
>> Edinburgh
>> EH9 3FD
>> T: +44(0)131 651 3465
>> E: dholmes at epcc.ed.ac.uk
>>
>> *Please consider the environment before printing this email.*
>>
>>
>>
>>
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>>
>> _______________________________________________
>> mpiwg-p2p mailing list
>> mpiwg-p2p at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p
>>
>
>
>
> --
> Jeff Hammond
> jeff.science at gmail.com
> http://jeffhammond.github.io/
>
>
> --
> Dan Holmes
> Applications Consultant in HPC Research
> EPCC, The University of Edinburgh
> James Clerk Maxwell Building
> The Kings Buildings
> Peter Guthrie Tait Road
> Edinburgh
> EH9 3FD
> T: +44(0)131 651 3465
> E: dholmes at epcc.ed.ac.uk
>
> *Please consider the environment before printing this email.*
>
>
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
> _______________________________________________
> mpiwg-p2p mailing list
> mpiwg-p2p at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-p2p/attachments/20151215/224dfc7a/attachment-0001.html>