<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 17, 2019 at 6:55 PM Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Jeff Hammond <<a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a>> writes:<br>
<br>
> When this was written, I was convinced that Dursi was wrong about<br>
> everything because one of the key arguments against MPI was<br>
> fault-intolerance, which I was sure was going to be solved soon.  However,<br>
> LLNL has done everything in their power to torpedo MPI fault-tolerance in<br>
> MPI-4 for the past 3+ years and I am no longer optimistic about MPI's<br>
> ability to grow outside of traditional HPC because of the forum's inability<br>
> to take fault-tolerance seriously.  It's also unclear that we can get by<br>
> without it in a post-exascale world.<br>
<br>
Have you seen any MPI FT proposals that would actually enable a<br>
collective library or application to meaningfully "recover"?<br>
<br>
Seems to me that in-memory checkpointing and process-based FT is more<br>
practical.  For example, you could have a Spark or Spark-like system<br>
that manages distributed in-memory data (perhaps standardizing on<br>
Arrow), launches MPI jobs to access that data in-place, and coordinates<br>
the distributed replication so that a fresh MPI job could restart on a<br>
(possibly) different group of nodes after the MPI job crashes.  In such<br>
a system, you would need to implement transactional updates to in-memory<br>
checkpoint data, but no special recovery from MPI (just that crashes be<br>
eventually collective, versus deadlock).<br>
</blockquote></div><div><br></div><div>Please look at <a href="https://prod-ng.sandia.gov/techlib-noauth/access-control.cgi/2016/1610522.pdf">https://prod-ng.sandia.gov/techlib-noauth/access-control.cgi/2016/1610522.pdf</a>.  This is similar to what you are proposing but without the expensive reboot of the MPI runtime.<br></div><div><br></div><div>Jeff</div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">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></div>