<div dir="ltr">> Jim - Should MPI_ERR_DATA_UNAVAILABLE be usable outside of RMA? Does it apply to point-to-point or collectives?<br><br>No.  RMA is the only context where data movement/access is decoupled from processing at the target.  It is impossible to make data available via two-sided communication if the/a target process is dead.<br><br>> Jim/Aurelien - Is the justification for this work that flush doesn't allow detection of process failure? They're still not convinced that this is true.<br><br>The issue is not that flush can't detect process failure in some cases.  It is that flush cannot detect process failure in all cases, and by cases, I mean implementations.  If your RMA implementation utilizes an ASIC, rather than the CPU, then it has no reason to determine if the target process is alive or not, and burdening it with doing so may be a performance disaster.<br><br>The other scenario where detecting if the target process is alive or not is anything like Casper, where the remote processing is done by an agent other than the target MPI process, although I recall that we discussed a model where any process failure associated with the communicator associated with a shared-memory window would need to take out all of those processes in order to have a sane model.<br><br>> Jim - On the other hand, it might be true that we can't guarantee any process failure detection in any RMA operation. Maybe we should just not allow process failure errors (as opposed to "upgrading" other types of errors to process failure).<br><br>There is no reason to disallow detecting of process failure.  We know many implementations use an active message implementation where such detection is trivial.<br><br>> Jim - One place this still makes sense as is is having a process with data corrupted because another process failed during a put. If a third process is reading the bad memory, it could get MPI_ERR_DATA_UNAVAILABLE instead of MPI_ERR_PROC_FAILED.<br><br>This sounds like the Byzantine problem.  MPI should not be responsible for detecting data corruption.<br><br>> We're still unclear on the failure model expected here. We probably need to get more feedback from Jeff.<br><br>First, all-or-nothing window invalidation is awful.  I think we've moved beyond that, but just to be sure, I'll justify why it's awful.<div><br>Some PGAS applications - NWChem being the most famous example - have read-only and update-only epochs, which are collective.  If a process fails, the application should be able to continue to use data that it knows programmatically could not have been modified during the epoch.  Furthermore, the application may know programmatically which processes touched which data and thus can recover some portion of the window(s) touched in an update-only epoch.</div><div><br></div><div>Second, I do not want to burden RMA implementations with "is target process alive?" active-message traffic in every communication operation, when the fault-intolerant implementation would not interact with the target process, e.g. RDMA networks.  I want an error code that RMA can use that recognizes that RMA decouples synchronization and data movement and that process live/dead checking is a form of synchronization.</div><div><br></div><div>Jeff<br><br>On Wed, Nov 1, 2017 at 6:24 AM, Bland, Wesley <<a href="mailto:wesley.bland@intel.com">wesley.bland@intel.com</a>> wrote:<br>><br>> I was waiting until you got back from leave.<br>><br>> We have some notes from the discussion two weeks ago on the wiki page: <a href="https://github.com/mpiwg-ft/ft-issues/wiki/2017-10-18">https://github.com/mpiwg-ft/ft-issues/wiki/2017-10-18</a>. We'd like to get a little more feedback on the failure model you were envisioning. It'd probably be most productive to do this on a call so we can get some back and forth.<br>><br>> Why don't we go ahead and cancel for this week. Jeff, can you attend next week? (Wednesdays at 12:00 PM Eastern US)<br>><br>> Thanks,<br>> Wesley<br>><br>> On Oct 31, 2017, at 4:46 PM, Jeff Hammond <<a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a>> wrote:<br>><br>> What feedback do you want? I haven’t seen any specific requests for comment.<br>><br>> Jeff<br>><br>> On Tue, Oct 31, 2017 at 1:04 PM Bland, Wesley <<a href="mailto:wesley.bland@intel.com">wesley.bland@intel.com</a>> wrote:<br>>><br>>> Hi all,<br>>><br>>> I think we're still on hold for the ULFM data resilience discussion until we're able to get some more feedback from Jeff and our non-ULFM topics are ready for another discussion with the rest of the forum.<br>>><br>>> Are there other topics that people want to discuss tomorrow or should we cancel the call?<br>>><br>>> Thanks,<br>>> Wesley<br>>> _______________________________________________<br>>> mpiwg-ft mailing list<br>>> <a href="mailto:mpiwg-ft@lists.mpi-forum.org">mpiwg-ft@lists.mpi-forum.org</a><br>>> <a href="https://lists.mpi-forum.org/mailman/listinfo/mpiwg-ft">https://lists.mpi-forum.org/mailman/listinfo/mpiwg-ft</a><br>><br>> --<br>> Jeff Hammond<br>> <a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a><br>> <a href="http://jeffhammond.github.io/">http://jeffhammond.github.io/</a><br>> _______________________________________________<br>> mpiwg-ft mailing list<br>> <a href="mailto:mpiwg-ft@lists.mpi-forum.org">mpiwg-ft@lists.mpi-forum.org</a><br>> <a href="https://lists.mpi-forum.org/mailman/listinfo/mpiwg-ft">https://lists.mpi-forum.org/mailman/listinfo/mpiwg-ft</a><br>><br>><br>><br>> _______________________________________________<br>> mpiwg-ft mailing list<br>> <a href="mailto:mpiwg-ft@lists.mpi-forum.org">mpiwg-ft@lists.mpi-forum.org</a><br>> <a href="https://lists.mpi-forum.org/mailman/listinfo/mpiwg-ft">https://lists.mpi-forum.org/mailman/listinfo/mpiwg-ft</a><br><br><br><br><br>--<br>Jeff Hammond<br><a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a><br><a href="http://jeffhammond.github.io/">http://jeffhammond.github.io/</a><br></div></div>