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

Mon Dec 14 09:59:34 CST 2015

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 
> <mailto: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>
>     <mailto:m.geimer at fz-juelich.de>
>     To: 	dholmes at epcc.ed.ac.uk <mailto:dholmes at epcc.ed.ac.uk>
>     CC: 	Marc-André Hermanns <m.a.hermanns at fz-juelich.de>
>     <mailto: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 <mailto: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 <mailto: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 <mailto:mpiwg-p2p at lists.mpi-forum.org>
>     http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p
>
>
>
>
> -- 
> Jeff Hammond
> jeff.science at gmail.com <mailto: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.*

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-p2p/attachments/20151214/ca6508ef/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-p2p/attachments/20151214/ca6508ef/attachment-0001.ksh>