July 2013 - mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] MPI_Win_lock_all() ordering question
by Michael Raymond 17 Jul '13

17 Jul '13

Thanks. Searching the tickets just now, I found #363. Are my issue and that ticket related? https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/363 On 07/17/2013 10:54 AM, Jim Dinan wrote: > Hi Michael, > > This believe that this can deadlock. I agree that it's unfortunate that > we didn't call it out in the spec, given that it would help to clarify > the intended semantics. > > ~Jim. > > > On Wed, Jul 17, 2013 at 11:41 AM, Michael Raymond <mraymond(a)sgi.com > <mailto:[email protected]>> wrote: > > I've got a question about the use of MPI_Win_lock_all() in the > face of competing MPI_Win_lock(EXCLUSIVE) calls. Consider the > following calls sequence: > > > 0 1 > MPI_Win_lock(EXCLUSIVE, 0) > > MPI_Win_lock(EXCLUSIVE, 1) MPI_Win_lock_all() > > .... .... > MPI_Win_unlock(1) MPI_Win_unlock_all() > MPI_Win_unlock(0) > > In this situation 0 has an exclusive lock on itself. > Simultaneously, 0 tries to get 1 exclusively and 1 tries to get a > shared lock on everyone. If 0 gets lucky, it will get to go first > and everything will go fine. If OTOH 1 locks itself shared and then > tries to lock 0 shared, deadlock ensues. You could argue that there > should be some global queue / governor that lets 0 go first, but > then I could see running into scalability problems. > > I can't find any place in the standard that says if the user > shouldn't do this, or if deadlock is allowed, or if the MPI > implementation should figure things out on its own. Thoughts? > > -- > Michael A. Raymond > SGI MPT Team Leader > (651) 683-3434 > > _________________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org <mailto:[email protected]> > http://lists.mpi-forum.org/__mailman/listinfo.cgi/mpi-forum > <http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum> > > > > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > -- Michael A. Raymond SGI MPT Team Leader (651) 683-3434

1 0

Re: [Mpi-forum] MPI_Win_lock_all() ordering question
by Jim Dinan 17 Jul '13

17 Jul '13

Hi Michael, This believe that this can deadlock. I agree that it's unfortunate that we didn't call it out in the spec, given that it would help to clarify the intended semantics. ~Jim. On Wed, Jul 17, 2013 at 11:41 AM, Michael Raymond <mraymond(a)sgi.com> wrote: > I've got a question about the use of MPI_Win_lock_all() in the face of > competing MPI_Win_lock(EXCLUSIVE) calls. Consider the following calls > sequence: > > > 0 1 > MPI_Win_lock(EXCLUSIVE, 0) > > MPI_Win_lock(EXCLUSIVE, 1) MPI_Win_lock_all() > > .... .... > MPI_Win_unlock(1) MPI_Win_unlock_all() > MPI_Win_unlock(0) > > In this situation 0 has an exclusive lock on itself. Simultaneously, 0 > tries to get 1 exclusively and 1 tries to get a shared lock on everyone. If > 0 gets lucky, it will get to go first and everything will go fine. If OTOH > 1 locks itself shared and then tries to lock 0 shared, deadlock ensues. You > could argue that there should be some global queue / governor that lets 0 > go first, but then I could see running into scalability problems. > > I can't find any place in the standard that says if the user shouldn't > do this, or if deadlock is allowed, or if the MPI implementation should > figure things out on its own. Thoughts? > > -- > Michael A. Raymond > SGI MPT Team Leader > (651) 683-3434 > > ______________________________**_________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/**mailman/listinfo.cgi/mpi-forum<http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum> >

1 0

Re: [Mpi-forum] MPI Ain't and MPI 3.1
by Jim Dinan 17 Jul '13

17 Jul '13

Hi Nick, I've just gotten around to updating the ticket with feedback from the June meeting. My apologies, the ticket was way out of sync with the progress on this issue. I'm hopeful that the new proposal text addresses your concerns with respect to segmented and tagged architectures: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349 The solution you described is similar to "proposed solution #2" on the ticket, which won't work for Fortran, because Fortran lacks the unsigned integers we would need for the MPI_Disp type. ~Jim. On Wed, Jul 17, 2013 at 8:03 AM, N.M. Maclaren <nmm1(a)cam.ac.uk> wrote: > On Jul 16 2013, Jim Dinan wrote: > >> >> I apologize for the long-delayed follow-up from our last meeting on how to >> handle the MPI Aint arithmetic ticket (tt #349). At the last meeting, we >> all agreed that this is an important fix that we would like to get out >> ASAP, but we weren't sure how to do it. I wanted to resume that >> discussion >> on the mailing list to get broader feedback and help move the discussion >> along in between meetings, if we can. >> > > This isn't about the procedure, but about the proposed solution. I think > that it is a serious mistake, and merely compounds the problems caused by > MPI_BOTTOM. The simplest resolution would be that the conversion functions > would take a window argument, as well, and that the > Aint/address/displacement were required to be associated with that window. > E.g.: > > int MPI_Get_disp(const void *location, MPI_Disp *disp, MPI_Win win); > int MPI_Aint_to_disp(MPI_Aint aint, MPI_Disp *disp, MPI_Win win); > int MPI_Disp_to_aint(MPI_Disp disp, MPI_Aint *aint, MPI_Win win); > > The point here is that even C still supports segmented and tagged memory > architectures. Currently, they are in abeyance, but they still exist and > they may return to the mainstream any time. The wording in the C (and even > C++) standard is phrased the way it is specifically to allow for such > things. Fortran, of course, has always supported them, and more. > > > Regards, > Nick Maclaren. > > > > ______________________________**_________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/**mailman/listinfo.cgi/mpi-forum<http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum> >

1 0

MPI_Win_lock_all() ordering question
by Michael Raymond 17 Jul '13

17 Jul '13

I've got a question about the use of MPI_Win_lock_all() in the face of competing MPI_Win_lock(EXCLUSIVE) calls. Consider the following calls sequence: 0 1 MPI_Win_lock(EXCLUSIVE, 0) MPI_Win_lock(EXCLUSIVE, 1) MPI_Win_lock_all() .... .... MPI_Win_unlock(1) MPI_Win_unlock_all() MPI_Win_unlock(0) In this situation 0 has an exclusive lock on itself. Simultaneously, 0 tries to get 1 exclusively and 1 tries to get a shared lock on everyone. If 0 gets lucky, it will get to go first and everything will go fine. If OTOH 1 locks itself shared and then tries to lock 0 shared, deadlock ensues. You could argue that there should be some global queue / governor that lets 0 go first, but then I could see running into scalability problems. I can't find any place in the standard that says if the user shouldn't do this, or if deadlock is allowed, or if the MPI implementation should figure things out on its own. Thoughts? -- Michael A. Raymond SGI MPT Team Leader (651) 683-3434

1 0

Re: [Mpi-forum] MPI Ain't and MPI 3.1
by N.M. Maclaren 17 Jul '13

17 Jul '13

On Jul 16 2013, Jim Dinan wrote: > >I apologize for the long-delayed follow-up from our last meeting on how to >handle the MPI Aint arithmetic ticket (tt #349). At the last meeting, we >all agreed that this is an important fix that we would like to get out >ASAP, but we weren't sure how to do it. I wanted to resume that discussion >on the mailing list to get broader feedback and help move the discussion >along in between meetings, if we can. This isn't about the procedure, but about the proposed solution. I think that it is a serious mistake, and merely compounds the problems caused by MPI_BOTTOM. The simplest resolution would be that the conversion functions would take a window argument, as well, and that the Aint/address/displacement were required to be associated with that window. E.g.: int MPI_Get_disp(const void *location, MPI_Disp *disp, MPI_Win win); int MPI_Aint_to_disp(MPI_Aint aint, MPI_Disp *disp, MPI_Win win); int MPI_Disp_to_aint(MPI_Disp disp, MPI_Aint *aint, MPI_Win win); The point here is that even C still supports segmented and tagged memory architectures. Currently, they are in abeyance, but they still exist and they may return to the mainstream any time. The wording in the C (and even C++) standard is phrased the way it is specifically to allow for such things. Fortran, of course, has always supported them, and more. Regards, Nick Maclaren.

1 0

Re: [Mpi-forum] MPI Ain't and MPI 3.1
by Schulz, Martin 17 Jul '13

17 Jul '13

Hi Jim, all, On Jul 16, 2013, at 3:40 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: > Hi All, > > I apologize for the long-delayed follow-up from our last meeting on how to handle the MPI Aint arithmetic ticket (tt #349). At the last meeting, we all agreed that this is an important fix that we would like to get out ASAP, but we weren't sure how to do it. I wanted to resume that discussion on the mailing list to get broader feedback and help move the discussion along in between meetings, if we can. > > We discussed incorporating this ticket as a 3.0 erratum, and there were concerns that this change might be too big for an erratum. To recap, ticket #349 adds a function, which would need to be included in the proper places in appendices and indexes. We would ideally also want to reference the function from the RMA text and update RMA examples to use the new function. > > Another option that we have not yet discussed is pushing out an MPI 3.1 spec. This would be another way of getting this change out before MPI 4.0. What is the general feeling on how soon we can release a 3.1 spec? Is this more palatable than handling this ticket as an erratum? A few other people have brought that up as well - I think we should have this discussion, but I fear it probably doesn't make sense to do this before the Chicago meeting, since many regular attendees will probably miss the Madrid meeting (I could be wrong, which would be great, of course). If we want to go that way, we should think about what is "permissible" for 3.1 and what should be 4.0. However, an MPI 3.1 wouldn't be that soon, either - even assuming (and this is VERY optimistic) all smaller changes that we would like to include are on the table and are "successfully" read and found consensus in Chicago, we still need three meetings after that (two votes and one full standard vote) before we can release an MPI 3.1, which would at least take us to September next year during the Japan meeting, i.e., a release at SC14. I am not saying this to suggest we shouldn't do a 3.1, but it is not a fast option to get important fixes out. Martin > > Thanks, > ~Jim. > > PS- https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349 > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum ________________________________________________________________________ Martin Schulz, schulzm(a)llnl.gov, http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA

1 0

MPI Ain't and MPI 3.1
by Jim Dinan 16 Jul '13

16 Jul '13

Hi All, I apologize for the long-delayed follow-up from our last meeting on how to handle the MPI Aint arithmetic ticket (tt #349). At the last meeting, we all agreed that this is an important fix that we would like to get out ASAP, but we weren't sure how to do it. I wanted to resume that discussion on the mailing list to get broader feedback and help move the discussion along in between meetings, if we can. We discussed incorporating this ticket as a 3.0 erratum, and there were concerns that this change might be too big for an erratum. To recap, ticket #349 adds a function, which would need to be included in the proper places in appendices and indexes. We would ideally also want to reference the function from the RMA text and update RMA examples to use the new function. Another option that we have not yet discussed is pushing out an MPI 3.1 spec. This would be another way of getting this change out before MPI 4.0. What is the general feeling on how soon we can release a 3.1 spec? Is this more palatable than handling this ticket as an erratum? Thanks, ~Jim. PS- https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349

1 0

Housing for the forum
by Richard Graham 15 Jul '13

15 Jul '13

Change of plan. The organizers have made arrangement for those who will only be attending the Forum to reserve a hotel room through the EuroMPI registration site. No charge for the registration, but hotel will need to be paid with a bank transfer. At this stage I will NOT be sending the organizers any hotel requests for the forum. I was able to reserve a room for both events through the website. Rich

1 0

Re: [Mpi-forum] MPI performance with Sophos Anti-Virus
by Wesley Bland 12 Jul '13

12 Jul '13

This list is not for MPI related questions, but for the standardization effort of the MPI Forum. Please direct your question to whichever MPI implementation you are using (MPICH, Open MPI, etc.). All of them have their own mailing lists to help with these sorts of issues. Wesley On Jul 12, 2013, at 6:10 AM, Abhinav Gupta <abhinav_gupta(a)mentor.com> wrote: > Hi, > > I am running a MPI application which is showing slowdown with Sophos anti-virus software installed. > I assume the anti-virus is checking every read-write access to disk from all the processes and thus serialising the parallel actions. > > Is there anything I can do either in MPI or in Sophos settings that will help. > > Abhinav > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

1 0

MPI performance with Sophos Anti-Virus
by Abhinav Gupta 12 Jul '13

12 Jul '13

Hi, I am running a MPI application which is showing slowdown with Sophos anti-virus software installed. I assume the anti-virus is checking every read-write access to disk from all the processes and thus serialising the parallel actions. Is there anything I can do either in MPI or in Sophos settings that will help. Abhinav

1 0