<div dir="ltr">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.<div><br></div><div>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.</div><div><br></div><div> ~Jim.<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 14, 2015 at 10:59 AM, Daniel Holmes <span dir="ltr"><<a href="mailto:dholmes@epcc.ed.ac.uk" target="_blank">dholmes@epcc.ed.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Hi Jeff,<br>
<br>
<blockquote type="cite">... tools can just intercept the info
operations and strip this key if they can't support it.<br>
</blockquote>
Agreed: this should have been response 4 on my list (Markus and I
discussed that option too).<br>
<br>
Cheers,<br>
Dan.<div><div class="h5"><br>
<br>
<div>On 14/12/2015 15:54, Jeff Hammond
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">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.
<div><br>
</div>
<div>If tools cannot handle MPI_THREAD_MULTIPLE already, then I
don't really care if they can't support this assertion either.</div>
<div><br>
</div>
<div>And in any case, such tools can just intercept the info
operations and strip this key if they can't support it.<br>
<div><br>
</div>
<div>Jeff</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Dec 14, 2015 at 7:44 AM, Daniel
Holmes <span dir="ltr"><<a href="mailto:dholmes@epcc.ed.ac.uk" target="_blank">dholmes@epcc.ed.ac.uk</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Hi all,<br>
<div><br>
Markus has reminded me that we discussed the effect of
the mpi_assert_allow_overtaking assertion on tools (see
below).<br>
<br>
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.<br>
<br>
My responses were:<br>
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<br>
2) the tool could hook all send and receive operations
and piggy-back a sequence number into the message header<br>
3) the tool could hook all send and receive operations
and serialise them to prevent overtaking<br>
I don't know the viability/acceptability of any of these
approaches.<br>
<br>
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.<br>
<br>
Cheers,<br>
Dan.<br>
<br>
-------- Forwarded Message --------
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
<th align="RIGHT" nowrap valign="BASELINE">Subject: </th>
<td>MPI P2P "messages may overtake" assertion</td>
</tr>
<tr>
<th align="RIGHT" nowrap valign="BASELINE">Date: </th>
<td>Mon, 14 Dec 2015 16:24:44 +0100</td>
</tr>
<tr>
<th align="RIGHT" nowrap valign="BASELINE">From: </th>
<td>Markus Geimer <a href="mailto:m.geimer@fz-juelich.de" target="_blank"><m.geimer@fz-juelich.de></a></td>
</tr>
<tr>
<th align="RIGHT" nowrap valign="BASELINE">To: </th>
<td><a href="mailto:dholmes@epcc.ed.ac.uk" target="_blank">dholmes@epcc.ed.ac.uk</a></td>
</tr>
<tr>
<th align="RIGHT" nowrap valign="BASELINE">CC: </th>
<td>Marc-André Hermanns <a href="mailto:m.a.hermanns@fz-juelich.de" target="_blank"><m.a.hermanns@fz-juelich.de></a></td>
</tr>
</tbody>
</table>
<br>
<br>
<pre>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: <a href="tel:%2B49-2461-61-1773" value="+492461611773" target="_blank">+49-2461-61-1773</a>
Fax: <a href="tel:%2B49-2461-61-6656" value="+492461616656" target="_blank">+49-2461-61-6656</a>
E-Mail: <a href="mailto:m.geimer@fz-juelich.de" target="_blank">m.geimer@fz-juelich.de</a>
WWW: <a href="http://www.fz-juelich.de/jsc" target="_blank">http://www.fz-juelich.de/jsc</a>
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
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
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
</pre>
<br>
<pre cols="72">--
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: <a href="tel:%2B44%280%29131%20651%203465" value="+441316513465" target="_blank">+44(0)131 651 3465</a>
E: <a href="mailto:dholmes@epcc.ed.ac.uk" target="_blank">dholmes@epcc.ed.ac.uk</a>
*Please consider the environment before printing this email.*</pre>
<br>
</div>
<br>
</div>
<br>
The University of Edinburgh is a charitable body, registered
in<br>
Scotland, with registration number SC005336.<br>
<br>
_______________________________________________<br>
mpiwg-p2p mailing list<br>
<a href="mailto:mpiwg-p2p@lists.mpi-forum.org" target="_blank">mpiwg-p2p@lists.mpi-forum.org</a><br>
<a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p" rel="noreferrer" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div>Jeff Hammond<br>
<a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a><br>
<a href="http://jeffhammond.github.io/" target="_blank">http://jeffhammond.github.io/</a></div>
</div>
</blockquote>
<br>
<pre cols="72">--
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: <a href="tel:%2B44%280%29131%20651%203465" value="+441316513465" target="_blank">+44(0)131 651 3465</a>
E: <a href="mailto:dholmes@epcc.ed.ac.uk" target="_blank">dholmes@epcc.ed.ac.uk</a>
*Please consider the environment before printing this email.*</pre>
</div></div></div>
<br>The University of Edinburgh is a charitable body, registered in<br>
Scotland, with registration number SC005336.<br>
<br>_______________________________________________<br>
mpiwg-p2p mailing list<br>
<a href="mailto:mpiwg-p2p@lists.mpi-forum.org">mpiwg-p2p@lists.mpi-forum.org</a><br>
<a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p" rel="noreferrer" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p</a><br></blockquote></div><br></div></div></div>