[Mpi-22] please review - Send Buffer Access (ticket #45)
Supalov, Alexander
alexander.supalov at [hidden]
Mon Dec 8 17:29:17 CST 2008
Dear Erez,
Thank you. I hope to have replied to your first question in my reply to Dick. It also contains a couple of other concerns I have identified so far in connection to ##45 and 46.
The review process definition - and Bill's clarification - are very helpful. I apparently missed this aspect because I did not attend the last meeting. It would be great to have those procedural decision communicated clearly to the Forum in some way after the meeting for the benefit of the absentees.
Basing on this definition, I agree that it will be correct to decouple the textual review from the substance discussion of ##45 and 46 that I started - without diminishing the import of either, of course.
I'm looking forward to the member's reaction to those concerns that I raised. I become more and more convinced that the proposed changes are going to harm more than they help.
Best regards.
Alexander
________________________________
From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba
Sent: Monday, December 08, 2008 10:12 PM
To: MPI 2.2
Subject: Re: [Mpi-22] please review - Send Buffer Access (ticket #45)
Dear Alexander,
As far as I recall memory remapping from the main processor to a network device was discussed before (If I recall correctly, in the April meeting). I think that it's close enough to your scenario of remapping to a different process for the purpose of this discussion.
Is your case real? Do you know of systems that do that with MPI? Or is it a hypothetical case?
For the review process, we do need people to review the text; we added this requirement in the last meeting. Regardless, it does not prevent any other person from giving feedback on the proposal. I'm sure that Jeff or Bill can give you're a more formal definition of the review process.
The wiki page state that:
https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/mpi22/TicketWorkflow
* To advance to the first reading, a proposal must be reviewed by the lead chapter author and three other reviewers. That review should check the change against the standard text to ensure that the change in context is correct; in addition, the change should be evaluated for completeness. For changes that involve multiple chapters (but are logically related and hence belong in a single ticket), the respective chapter authors must review the changes in their chapters. These reviews must be entered as comments on the ticket. MPI 2.2 Chapter Authors<https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/MPI2.2ChapterAuthors>
From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander
Sent: Saturday, December 06, 2008 11:44 AM
To: MPI 2.2
Subject: Re: [Mpi-22] please review - Send Buffer Access (ticket #45)
Dear Erez,
Thank you. I agree to respectfully disagree on this with you, for the following two reasons:
1) The memory remapping scenario IO brought up a couple of days ago was not discussed before the first voting as far as I can recall. If you have proof to the contrary, I would most kindly ask you to present it. If this cannot be done, I would say that a new issue has been added to the discussion, and we may need to review its substance.
2) Next, I would like to see the definition of the ticket review process that states the reviewers are supposed to only check the proposed text for correspondence with the existing standard. My opinion is that reviewers are there to bring both textual and substantial concerns up when they see the need for this. So far I've been acting on this conviction.
I'm looking forward to the further discussion on the floor.
Best regards.
Alexander
________________________________
From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba
Sent: Saturday, December 06, 2008 7:45 PM
To: MPI 2.2
Subject: Re: [Mpi-22] please review - Send Buffer Access (ticket #45)
Thanks Alexander,
I respectfully decline your proposal to suspend the review of these tickets.
I don't see any specific reference wrt text in your comments; and you don't bring any new issue that has not been discussed before the 1st voting. Thus I don't see any reason to suspend their review.
Thanks,
.Erez
From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander
Sent: Friday, December 05, 2008 4:19 PM
To: MPI 2.2
Subject: Re: [Mpi-22] please review - Send Buffer Access (ticket #45)
Dear Erez,
Thank you. I reviewed the text and found that further polishing of its textual aspects should be suspended until the substance is clarified. I put a comment to this effect into the ticket, as well as into the dependent ticket #46. In my opinion, both tickets are not yet ready to go into the standard and should go into another round of contemplation of their possible repercussions.
In both cases presumed application friendliness is traded for less freedom of implementation. Application developers who disregard the standard now will most likely continue to do this in the future, possibly in some other way. Restricting the freedom of implementation to make their life easier does not seem to be an attractive proposition to me.
If any of the issues identified so far, or comparable issues we cannot fathom at the moment, surface up in one of the future HPC platforms and hinder MPI adoption or transition to MPI-2.2 there, we will have done disservice both to the MPI standard and to the community. I hope this will bear on the minds of those who're going to vote on these two items at the meeting.
Best regards.
Alexander
________________________________
From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba
Sent: Saturday, December 06, 2008 12:28 AM
To: MPI 2.2
Subject: Re: [Mpi-22] please review - Send Buffer Access (ticket #45)
Dear Alexander,
It is okay and encouraged for people to comment and argue on the proposals. You can add your comments to the ticket arguing your important points. The forum then consider that various points and vote on the proposal.
However for the voting process we need people to review the text and confirm that it does not conflict with the standard and it is reasonable (from language pov) to be included in the standard.
If we are willing to review the text and state that it valid for the standard, that would be great. If you have any comments on the text please send them to me.
Thanks,
.Erez
From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander
Sent: Friday, December 05, 2008 2:26 PM
To: MPI 2.2
Subject: Re: [Mpi-22] please review - Send Buffer Access (ticket #45)
Dear Erez,
Thank you. I'm afraid I would need to have it explained in more detail why review may not include arguments on the substance. If something in the proposal makes one think that the proposed matter may be detrimental to the MPI standard and its implementations, I consider it one's duty to point this out.
Following up on your reply: the segfault situation you described will make an MPI compliant program break. Thus, the implementation will have to keep the send buffer mapped into the sending process address space. This is a limitation on the MPI implementation that should be taken into account during the voting.
Another possibility that has been pointed out earlier was that the proposed change disallows byte swap and other send buffer conversions to be done in place. At least one historical MPI implementation was doing this to a great avail. Who knows what is going to happen in the future?
Best regards.
Alexander
________________________________
From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba
Sent: Friday, December 05, 2008 11:18 PM
To: MPI 2.2
Subject: Re: [Mpi-22] please review - Send Buffer Access (ticket #45)
I think that the idea is for the reviewers to check the text for any mistakes and compatibility with the existing text, rather than check for the validity of the proposal. The later as I recall is left for the MPI forum assembly.
As for your question, I'm sure that you can answer it yourself. :) If the memory is still also mapped to the original process (as with shared memory) that everything is fine. If the memory is removed from the original process, than the app will get an access-violation fault.
(if this system works on a page boundary, to take this action it needs to make sure that there are no other allocation on the same page)
Thanks,
.Erez
From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Supalov, Alexander
Sent: Friday, December 05, 2008 2:05 PM
To: MPI 2.2
Subject: Re: [Mpi-22] please review - Send Buffer Access (ticket #45)
Hi,
I'd like to review this proposal. Let's consider the following scenario:
- In the MPI_Isend, MPI maps the send buffer into the address space of the receiving process.
- In the matching MPI_Recv, the receiving process makes a copy of the mapped send buffer into the receive buffer.
- Once the copy is complete, the send buffer is mapped back into the sender address space during the wait/test call.
What will happen one tries to access the send buffer in between?
Best regards.
Alexander
________________________________
From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Erez Haba
Sent: Friday, December 05, 2008 10:48 PM
To: MPI 2.2
Subject: [Mpi-22] please review - Send Buffer Access (ticket #45)
This proposal has passed 1st voting and needs reviewers. We need 3 volunteers to sign-off on this proposal, plus the 3 chapter authors to sign-off on the text.
The Chapter Authors for
Chapter 3: Point-to-Point Communication
Chapter 5: Collective Communication
Chapter 11: One-Sided Communication
Please add a comment to the ticket saying that you reviewed the proposal, or please send me your comments.
Send Buffer Access: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/45
Thanks,
.Erez
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-22/attachments/20081208/1facf71b/attachment.html>
More information about the Mpi-22
mailing list