At 06:36 AM 4/21/2008, Terry Dontje wrote:
>So I reread the piggybacking document on wiki. I am not thrilled with
>the amount of new APIs this would be adding to the standard but can also
>see the point of the paper. I am curious how the new API is expected to
>be used? The proposal say's this API is needed for user-level fault
>tolerance solutions. So do we expect a user to change all application
>calls to the MPI library to use the PB calls? I wonder if a more
>general solution that doesn't require a direct change to the API would work.
Layers like the one for fault tolerance will have to intercept
all MPI communication calls anyway (otherwise it will not be
possible to capture the state of the MPI layer) and hence the
most likely mechanism to implement them is the PMPI layer. At
this point it will be very easy and fully transparent to also
replace communication calls with the piggyback counterparts.
The application would not see the difference (if we get the API
right :) ).
>I wonder if there might be a way one could register piggybacking with a
>communicator and somehow have the actual piggybacking occur as a
>callback from an implementations messaging layer?
Registering piggyback data beforehand (whether per communicator
or globally) has the problem that in a fully multithreaded use
of MPI piggyback data can no longer be associated with a single
MPI call/message (unless we make the piggyback data thread local,
but this would require a concept of threads in MPI and I don't
think we should go there).
Martin
>Just a thought,
>
>--td
>_______________________________________________
>mpi3-ft mailing list
>mpi3-ft(a)lists.mpi-forum.org
>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
_______________________________________________________________________
Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulz6
CASC @ Lawrence Livermore National Laboratory, Livermore, USA
The following papers should clarify the motivation and the usage mechanism:
http://greg.bronevetsky.com/papers/2003PPoPP.pdfhttp://sc07.supercomputing.org/schedule/pdf/pap224.pdf
The first describes a checkpointing protocol that was implemented on
top of MPI. The library intercepted all application MPI calls and
added appropriate piggybacking and message logging logic to ensure
that regardless of when each application process decided to take a
checkpoint, it would still be possible to put together a consistent
global state on restart. The user did not need to add any code.
The second paper describes a library called PnMPI that uses the PMPI
interface to make it possible to insert as many PMPI interception
layers as one would like, with the possibility of having them
interact and use each other's functionality. We expect that the
piggybacking interface will primarily be used by tools written at
this level, using tools like PnMPI or just plain PMPI. In particular,
our focus here is on tool builders, not application programmers and
we believe that APIs like this will be useful to all application
developers simply because they're important to tool builders whose
tools may be used by any developer.
In addition to checkpointing, piggybacking is useful for tracing
libraries, performance analysis tools and generic libraries that need
to lazily propagate information and would prefer not to introduce any
new communication for performance reasons.
Greg Bronevetsky
Post-Doctoral Researcher
1028 Building 451
Lawrence Livermore National Lab
(925) 424-5756
bronevetsky1(a)llnl.gov
At 06:36 AM 4/21/2008, Terry Dontje wrote:
>So I reread the piggybacking document on wiki. I am not thrilled with
>the amount of new APIs this would be adding to the standard but can also
>see the point of the paper. I am curious how the new API is expected to
>be used? The proposal say's this API is needed for user-level fault
>tolerance solutions. So do we expect a user to change all application
>calls to the MPI library to use the PB calls? I wonder if a more
>general solution that doesn't require a direct change to the API would work.
>
>I wonder if there might be a way one could register piggybacking with a
>communicator and somehow have the actual piggybacking occur as a
>callback from an implementations messaging layer?
>
>Just a thought,
>
>--td
>_______________________________________________
>mpi3-ft mailing list
>mpi3-ft(a)lists.mpi-forum.org
>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
So I reread the piggybacking document on wiki. I am not thrilled with
the amount of new APIs this would be adding to the standard but can also
see the point of the paper. I am curious how the new API is expected to
be used? The proposal say's this API is needed for user-level fault
tolerance solutions. So do we expect a user to change all application
calls to the MPI library to use the PB calls? I wonder if a more
general solution that doesn't require a direct change to the API would work.
I wonder if there might be a way one could register piggybacking with a
communicator and somehow have the actual piggybacking occur as a
callback from an implementations messaging layer?
Just a thought,
--td
Just a reminder that we are planning to make up the missed call from last
week. We will have the a call at noon EST. If I forget the call, please
call me - some on the call have my number, and I can send it to individuals.
Thanks,
Rich
I have updated the wiki with some more precise language about the
process management proposal. It still needs work in the connect/accept
section, but the other sections are done for the moment.
-- Josh
On Apr 11, 2008, at 10:42 AM, Josh Hursey wrote:
> I just updated the Process Management proposal in the wiki:
> http://svn.mpi-forum.org/trac/mpi-forum-web/wiki/Async-proc-mgmt
>
> This contains discussion of the non-blocking process management
> interfaces. It also moved the discussion of connect/accept extensions
> from the FT Mgr/worker proposal to this one for consolidation
> purposes. I put a note in the FT Mgr/Worker proposal indicating this
> transition, but did not remove any of the original text from it so we
> can have it as a reference.
>
> This should be regarded as a rough draft still as I made no actual
> attempt at writing precise standardize language, but opted for a more
> casual presentation so we can more freely discuss the high level
> merits of the proposal.
>
> Sorry for the delay on this. I was hoping to finish it earlier to
> allow more time for review before the teleconf.
>
> Cheers,
> Josh
>
> _______________________________________________
> mpi3-ft mailing list
> mpi3-ft(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
This was 100% my fault, I just spaced it out. By the time I got on late,
only
2 people were on the line, so we decided to move this to Friday next week
same time.
Sorry,
Rich
On 4/11/08 12:28 PM, "Adam Moody" <moody20(a)llnl.gov> wrote:
> Also, can someone send an email once the call actually starts? It keeps
> kicking me out after some time, and I imagine it's expensive for some to
> call in and wait.
> -Adam
>
> Greg Bronevetsky wrote:
>
>> >Are the call details posted anywhere? I've been trying to use telecon
>> >numbers from past calls but I'm getting an un-initialized conference.
>> >
>> >Greg Bronevetsky
>> >Post-Doctoral Researcher
>> >1028 Building 451
>> >Lawrence Livermore National Lab
>> >(925) 424-5756
>> >bronevetsky1(a)llnl.gov
>> >
>> >At 09:11 AM 4/7/2008, Richard Graham wrote:
>> >
>> >
>>> >>Just a reminder that we have a call this coming Friday, 4/11. I would
>>> like
>>> >>to briefly go over the MPI dynamics recommended changes to make sure we
>>> are
>>> >>ready with this for the next forum meeting, and also continue discussing
>>> the
>>> >>error handling mechanisms we will propose. In addition, if time permits,
I
>>> >>would like to discuss the data piggybacking proposal. Anything else that
>>> >>needs to be discussed ?
>>> >>
>>> >>Thanks,
>>> >>Rich
>>> >>
>>> >>_______________________________________________
>>> >>mpi3-ft mailing list
>>> >>mpi3-ft(a)lists.mpi-forum.org
>>> >>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
>>> >>
>>> >>
>> >
>> >_______________________________________________
>> >mpi3-ft mailing list
>> >mpi3-ft(a)lists.mpi-forum.org
>> >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
>> >
>> >
>> >
> _______________________________________________
> mpi3-ft mailing list
> mpi3-ft(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
>
Also, can someone send an email once the call actually starts? It keeps
kicking me out after some time, and I imagine it's expensive for some to
call in and wait.
-Adam
Greg Bronevetsky wrote:
>Are the call details posted anywhere? I've been trying to use telecon
>numbers from past calls but I'm getting an un-initialized conference.
>
>Greg Bronevetsky
>Post-Doctoral Researcher
>1028 Building 451
>Lawrence Livermore National Lab
>(925) 424-5756
>bronevetsky1(a)llnl.gov
>
>At 09:11 AM 4/7/2008, Richard Graham wrote:
>
>
>>Just a reminder that we have a call this coming Friday, 4/11. I would like
>>to briefly go over the MPI dynamics recommended changes to make sure we are
>>ready with this for the next forum meeting, and also continue discussing the
>>error handling mechanisms we will propose. In addition, if time permits, I
>>would like to discuss the data piggybacking proposal. Anything else that
>>needs to be discussed ?
>>
>>Thanks,
>>Rich
>>
>>_______________________________________________
>>mpi3-ft mailing list
>>mpi3-ft(a)lists.mpi-forum.org
>>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
>>
>>
>
>_______________________________________________
>mpi3-ft mailing list
>mpi3-ft(a)lists.mpi-forum.org
>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
>
>
>
Are the call details posted anywhere? I've been trying to use telecon
numbers from past calls but I'm getting an un-initialized conference.
Greg Bronevetsky
Post-Doctoral Researcher
1028 Building 451
Lawrence Livermore National Lab
(925) 424-5756
bronevetsky1(a)llnl.gov
At 09:11 AM 4/7/2008, Richard Graham wrote:
>Just a reminder that we have a call this coming Friday, 4/11. I would like
>to briefly go over the MPI dynamics recommended changes to make sure we are
>ready with this for the next forum meeting, and also continue discussing the
>error handling mechanisms we will propose. In addition, if time permits, I
>would like to discuss the data piggybacking proposal. Anything else that
>needs to be discussed ?
>
>Thanks,
>Rich
>
>_______________________________________________
>mpi3-ft mailing list
>mpi3-ft(a)lists.mpi-forum.org
>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
I think we are all waiting on Rich to enter the call. :/ Till then we
are on hold.
On Apr 11, 2008, at 12:12 PM, Supalov, Alexander wrote:
> Hi,
>
> I can't get on the call. Can you?
>
> Best regards.
>
> Alexander
>
> -----Original Message-----
> From: mpi3-ft-bounces(a)lists.mpi-forum.org
> [mailto:[email protected]] On Behalf Of Richard
> Graham
> Sent: Monday, April 07, 2008 6:12 PM
> To: MPI 3.0 Fault Tolerance and Dynamic Process Control working Group
> Subject: [Mpi3-ft] Next con call.
>
> Just a reminder that we have a call this coming Friday, 4/11. I would
> like
> to briefly go over the MPI dynamics recommended changes to make sure
> we
> are
> ready with this for the next forum meeting, and also continue
> discussing
> the
> error handling mechanisms we will propose. In addition, if time
> permits, I
> would like to discuss the data piggybacking proposal. Anything else
> that
> needs to be discussed ?
>
> Thanks,
> Rich
>
> _______________________________________________
> mpi3-ft mailing list
> mpi3-ft(a)lists.mpi-forum.org
> 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
> mpi3-ft(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
More expensive than iTune if you call overseas. :)
-----Original Message-----
From: mpi3-ft-bounces(a)lists.mpi-forum.org
[mailto:[email protected]] On Behalf Of Narasimhan,
Kannan
Sent: Friday, April 11, 2008 6:12 PM
To: MPI 3.0 Fault Tolerance and Dynamic Process Control working Group
Subject: Re: [Mpi3-ft] Next con call.
Me too. Pleasant music, though ...
-Kannan-
-----Original Message-----
From: mpi3-ft-bounces(a)lists.mpi-forum.org
[mailto:[email protected]] On Behalf Of Josh Hursey
Sent: Friday, April 11, 2008 11:10 AM
To: MPI 3.0 Fault Tolerance and Dynamic Process Control working Group
Subject: Re: [Mpi3-ft] Next con call.
Is the below the correct information for the call?
US Toll Free number: 877-801-8130, Toll number: 1-203-692-8690,
Code: 1044056
I'm on hold.
On Apr 7, 2008, at 12:11 PM, Richard Graham wrote:
> Just a reminder that we have a call this coming Friday, 4/11. I would
> like to briefly go over the MPI dynamics recommended changes to make
> sure we are ready with this for the next forum meeting, and also
> continue discussing the error handling mechanisms we will propose. In
> addition, if time permits, I would like to discuss the data
> piggybacking proposal. Anything else that needs to be discussed ?
>
> Thanks,
> Rich
>
> _______________________________________________
> mpi3-ft mailing list
> mpi3-ft(a)lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
_______________________________________________
mpi3-ft mailing list
mpi3-ft(a)lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
_______________________________________________
mpi3-ft mailing list
mpi3-ft(a)lists.mpi-forum.org
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.
