<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Aug 19, 2013, at 5:48 PM, George Bosilca <<a href="mailto:bosilca@icl.utk.edu">bosilca@icl.utk.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><base href="x-msg://5249/"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Wesley, all,</div><div><br></div><div>Here are few comments/suggestions on the slides.</div><div><br></div>Slide 7: There is a mention about "re-enabling wildcard operations". While this is technically true, it is only a side effect of the real operation, acknowledging the local understanding of failure state. This is the reason why the corresponding function is called MPI_Comm_failure_ack and not MPI_Comm_reenable_any_source.</div></blockquote><div><br></div><div>I've reversed those two bullets and added a few more words to make it more clear that getting the failed processes is the primary purpose:</div><div><br></div><div>"Re-enables wildcard operations on a communicator now that the user knows about the failures"</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>Slide 8: - "as it impacts completion" ? What completion?</div></div></blockquote><div><br></div><div>New text: "Let the application discover the error as it impacts correct completion of an operation."</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div> - "in the same communicator" is unclear.</div></div></blockquote><div><br></div><div>I'm not sure what about this is unclear. If you can suggest some new text that would improve it, I would appreciate that.</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>Slide 9: I have few issues with this slide. "How does the application know which request to restart?" Well, if there is anybody that might have the slightest chance to know what requests are still needed … it's the application. Second, I don't see the point of promising a follow-up proposal.</div></div></blockquote><div><br></div><div>Part of the idea of these slides is to discuss the design rationale. One of the discussions we've had with a number of people is that making revoke a permanent operation is unnecessary. This slide describes why we think it is necessary to have as simple a proposal as possible. If we want more full-featured things, like a temporary revoke state, it's possible to do that, but it needs to happen later in order to not complicate this one.</div><div><br></div><div>I've softened the text to say that it "could" come as a follow-on proposal.</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>Slide 10: - Shouldn't be "failed processes"?</div></div></blockquote><div><br></div><div>Yes. Fixed.</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div> - The need for collective communications is not the only reason to use MPI_Comm_shrink. I would use a more general formulation: "When collective knowledge is necessary…".</div></div></blockquote><div><br></div><div>It isn't the only reason, but we're not trying to be cryptic in this talk. This is demonstrating a real use case for this function. There are others of course.</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div> - The MPI_Comm_shrink is doing more than just creating a slimmed down communicator. It validates a global view of all the failed processes in the original communicator on the participating nodes. From my perspective this is more important that creating the new communicator.</div></div></blockquote><div><br></div><div>You're right. This is one of the things we discussed at the UTK face-to-face that I failed to add to the slides. Shrink can be used as a replacement for acquiring knowledge of global failures at the same cost as creating a function that would do this explicitly. I've added the following text:</div><div><br></div><div>* Can also be used to validate knowledge of all failures in a communicator.<br> * Shrink the communicator, compare the new group to the old one, free the new communicator (if not needed).<br> * Same cost as querying all processes to learn about all failures</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>Slide 11: I would suggest to change the wording in order to replace "throw away" by "release". The example on the next slide is doing exactly this.</div></div></blockquote><div><br></div><div>In my mind it (informally) means the same thing, but if we need to be precise on these slides, so be it. I've changed that.</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>Slide 12: This example is __not__ correct as using the same pointer as send and receive buffer in the MPI_Allreduce (use MPI_IN_PLACE instead) is clearly forbidden my the standard.</div></div></blockquote><div><br></div><div>Fixed. Lazy coding.</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>Slide 13: I would be careful what you wish for. There are very good reasons why an MPI_Comm_free is a collective call. I would think a little more about this before pushing for a radical requirement.</div></div></blockquote><div><br></div><div>Of course it should still be a collective call. This is only saying that if everything else is broken, you should still have the option to free the memory associated with the handle. What are some of the downsides for this? The pending operations on the communicator were either already going to fail or should be able to complete (collectives fail, pt2pt complete). The implementation probably needs to be careful about reference counting to make sure that the handle isn't being pulled out from under something that's still using it, but that shouldn't be a big problem.</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>Slide 16: This example is not correct without an explicit agreement at every level up the stack. There are many ways for it to fail, too many to let it on the wild.</div></div></blockquote><div><br></div><div>You're right that this isn't a complete example, but it is there to convey the general idea. If the group thinks it's doing more harm than good by being in the slides, it can go, but library composition is something that we've been asked about many times. Should we trash this and come up with something more extended?</div><div><br></div><div>Another version of the corrected slides is attached.</div><div><br></div><div><div>Thanks,</div><div>Wesley</div></div><div><br></div></div></body></html>