My point is that each MPI implementation will have to negotiate with each checkpointer what this call will mean on each platform, meaning that it is upto the implementation-specific call to do all that magic. It doesn't save the application any real effort to call this routine by its implementation-specific name rather than a unified name given that the other two major problems are not solved: - Providing a uniform way for checkpointers and MPI implementations to interact (THE major for having this proposal in the first place) and - Support for more than the synch-and-stop checkpointing protocol, which does scales poorly with rising failure rates. My point here is that covering one of the three major issues is not good enough to modify the MPI specification and I don't think that we'll ever be able to do more than that. We're pretty much agreed in the working group that the first point above cannot be done and I don't think that the second can be done without providing callbacks to be called for each incoming/outgoing message. Greg Bronevetsky Post-Doctoral Researcher 1028 Building 451 Lawrence Livermore National Lab (925) 424-5756 [email protected] http://greg.bronevetsky.com At 08:40 AM 2/18/2009, Supalov, Alexander wrote:

Thanks. How will the checkpointer-specific call talk to the MPI?

-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Greg Bronevetsky Sent: Wednesday, February 18, 2009 5:29 PM To: MPI 3.0 Fault Tolerance and Dynamic Process Control working Group; MPI 3.0 Fault Tolerance and Dynamic Process Control working Group Subject: Re: [Mpi3-ft] Communicator Virtualization as a step forward

...

Thanks. How will you let the MPI know the checkpoint is coming, to give it a fair chance to prepare to this and then recover after the checkpoint? This is akin to the MPI_Finalize/MPI_Init in some sense, midway thru the job, hence the analogy.

Just use the checkpointer-specific call. The call is going to have checkpointer-specific semantics, so why not give it a checkpointer-specific name? I understand that there is some use to allowing applications to use the same name across all checkpointers but the bar should be higher than that for adding something to the standard. Also, right now the whole approach inherently only supports one checkpointing protocol: synch-and-stop. If we can work out a more generic API that supports other protocols I think that it may have enough value to be included in the spec. Right now it still hasn't passed the bar.

Greg Bronevetsky Post-Doctoral Researcher 1028 Building 451 Lawrence Livermore National Lab (925) 424-5756 [email protected] http:// greg.bronevetsky.com

_______________________________________________ mpi3-ft mailing list [email protected] http:// lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft --------------------------------------------------------------------- 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.

_______________________________________________ mpi3-ft mailing list [email protected] http:// lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft