December 2011 - mpiwg-rma - mailman3.cels.anl.gov

Re: [Mpi3-rma] Next RMA Telecon
by Pavan Balaji 26 Dec '11

26 Dec '11

On 12/09/2011 03:36 PM, Torsten Hoefler wrote: >> 3) allocate_shared proposal with MPI_Win_lock_all(exclusive) > - remove MPI_Win_lock_all(exclusive) from the proposal and re-read Why was this removed? -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

[Mpi3-rma] RMA WG Readings
by Torsten Hoefler 13 Dec '11

13 Dec '11

Hello All, Here is a quick overview of the RMA group's proposals for the next meeting. Readings: 1a) https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/284 (Tue 2:30-4:30) (the RMA WG found that it is appropriate to prohibit MPI_WIN_LOCK_ALL(exclusive), i.e., we need to re-read with this change) 2) minor corrections to the chapter 2a) https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/309 (Tue 2-2:15) 2b) https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/308 (Tue 2:15-2:30) 2c) https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/283 (Tue 3:30-4:30) (tagged on to #284) Votes: 3) https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/270 (Mon 4-4:15) 4) https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/299 (Mon 4:15-4:30) 5) https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/298 (Mon 4:30-4:45) Thanks & All the Best, Torsten -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- Torsten Hoefler | Performance Modeling and Simulation Lead Blue Waters Directorate | University of Illinois (UIUC) 1205 W Clark Street | Urbana, IL, 61801 NCSA Building | +01 (217) 244-7736

1 0

Re: [Mpi3-rma] Next RMA Telecon
by Jim Dinan 12 Dec '11

12 Dec '11

Hi All, I've converted ticket #283 into a proper proposal, please take a look and send any feedback. Absent from this proposal is any mention of Fortran types, since everything in the Fortran attributes interface must be an INTEGER (KIND=MPI_ADDRESS_KIND). Also note, as discussed in the last telecon, that this ticket is strictly a clarification. A search of the 2.2 document turns up on page 509, line 12: "... in Fortran, MPI_WIN_GET_ATTR(win, MPI_WIN_BASE, val, ag, ierror) will return in val the base address of the window, converted to an integer. In C, MPI_Win_get_attr(win, MPI_WIN_BASE, &p, & ag) will return in p a pointer to the window base, cast to (void *)." Cheers, ~Jim. On 12/9/11 6:06 PM, Torsten Hoefler wrote: > On Fri, Dec 09, 2011 at 05:57:00PM -0600, James Dinan wrote: >> I've updated ticket #283 with a table of data types for >> MPI_Win_get/set_attr: >> >> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/283 >> >> It turns out that these are actually somewhat defined in the standard >> text (even for the new types), but it requires a careful/creative >> reading of the text. We could get away without this ticket, but I think >> that it's a a good clarification. >> >> The Fortran types all have to be INTEGER (KIND=MPI_ADDRESS_KIND) because >> of the function definition for get/set_attr. The C types vary as shown >> in the table. >> >> Please send any feedback. I'll put this into Latex for the next meeting. > Great, thanks! > > Can you please put this into a full proposal format ala. "insert the > following text and table at page XXX line XXX". Turning this into a > Latex table is trivial. > > Thanks& Best, > Torsten >

1 0

Re: [Mpi3-rma] Next RMA Telecon
by Torsten Hoefler 09 Dec '11

09 Dec '11

On Fri, Dec 09, 2011 at 05:57:00PM -0600, James Dinan wrote: > I've updated ticket #283 with a table of data types for > MPI_Win_get/set_attr: > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/283 > > It turns out that these are actually somewhat defined in the standard > text (even for the new types), but it requires a careful/creative > reading of the text. We could get away without this ticket, but I think > that it's a a good clarification. > > The Fortran types all have to be INTEGER (KIND=MPI_ADDRESS_KIND) because > of the function definition for get/set_attr. The C types vary as shown > in the table. > > Please send any feedback. I'll put this into Latex for the next meeting. Great, thanks! Can you please put this into a full proposal format ala. "insert the following text and table at page XXX line XXX". Turning this into a Latex table is trivial. Thanks & Best, Torsten -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- Torsten Hoefler | Performance Modeling and Simulation Lead Blue Waters Directorate | University of Illinois (UIUC) 1205 W Clark Street | Urbana, IL, 61801 NCSA Building | +01 (217) 244-7736

1 0

Re: [Mpi3-rma] Next RMA Telecon
by Jim Dinan 09 Dec '11

09 Dec '11

I've updated ticket #283 with a table of data types for MPI_Win_get/set_attr: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/283 It turns out that these are actually somewhat defined in the standard text (even for the new types), but it requires a careful/creative reading of the text. We could get away without this ticket, but I think that it's a a good clarification. The Fortran types all have to be INTEGER (KIND=MPI_ADDRESS_KIND) because of the function definition for get/set_attr. The C types vary as shown in the table. Please send any feedback. I'll put this into Latex for the next meeting. ~Jim. On 12/9/11 5:39 PM, Torsten Hoefler wrote: > Hello Again, > > I created ticket #308 and #309 (I'm not 100% convinced by #309). Please > comment as appropriate. > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/308 > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/309 > > I also removed win_lock_all(exclusive) from #284. > > https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/284 > > I also talked to Marc and he explained that the idea was that the lock > can essentially be implemented as nonblocking (blocking at first use). > However, together with local buffering (the first n puts may be > nonblocking and the n-th put may block after the buffer is exhausted), > this could create arbitrary blocking RMA operations (from a user's > perspective). Marc agreed that this may be hard to program. So this > functionality was clearly intended but the consequences may not be and > this issue may need to be fixed. > > He will look into this in detail and get back to us. > > Thanks& Best, > Torsten > >> The telecon ended after 1.5 hours and I'm summarizing our discussions >> and decisions below: >> >>> 1) Adam's suggestion that datatype offsets have to be relative to MPI_BOTTOM >> - Torsten creates a ticket to remove this sentence >> >>> 2) disp_unit should not be fixed (one can create one window for each) >> - this issue was resolved and the comment will be ignored by Adam's >> advice >> >>> 3) allocate_shared proposal with MPI_Win_lock_all(exclusive) >> - remove MPI_Win_lock_all(exclusive) from the proposal and re-read >> >>> 4) ticket 300: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/300 >> - Torsten will talk to Marc and report back >> >>> 5) ticket 283: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/283 >> - Jim will bring a full proposal forward >> >>> 6) Adam suggested: p23, 6-7 Regarding status, we should either say that >>> all fields are undefined (except for the error) or we should specify >>> all values, e.g., what about values returned for MPI_GET_COUNT, >>> MPI_GET_ELEMENTS, or MPI_TEST_CANCELLED? Replace "The values of the >>> MPI_SOURCE and MPI_TAG fields are undefined." with "All other fields >>> in status are undefined." -- Question: Would it be useful to set >>> fields for count and get elements? >> - Torsten will create a ticket to clarify that everything that is not >> explicitly specified remains undefined (similar to I/O) >> >> Comments are welcome! >> >> Thanks& Best, >> Torsten >> >> -- >> bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- >> Torsten Hoefler | Performance Modeling and Simulation Lead >> Blue Waters Directorate | University of Illinois (UIUC) >> 1205 W Clark Street | Urbana, IL, 61801 >> NCSA Building | +01 (217) 244-7736 >> _______________________________________________ >> mpi3-rma mailing list >> mpi3-rma(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma >> >

1 0

Re: [Mpi3-rma] Next RMA Telecon
by Torsten Hoefler 09 Dec '11

09 Dec '11

Hello Again, I created ticket #308 and #309 (I'm not 100% convinced by #309). Please comment as appropriate. https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/308 https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/309 I also removed win_lock_all(exclusive) from #284. https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/284 I also talked to Marc and he explained that the idea was that the lock can essentially be implemented as nonblocking (blocking at first use). However, together with local buffering (the first n puts may be nonblocking and the n-th put may block after the buffer is exhausted), this could create arbitrary blocking RMA operations (from a user's perspective). Marc agreed that this may be hard to program. So this functionality was clearly intended but the consequences may not be and this issue may need to be fixed. He will look into this in detail and get back to us. Thanks & Best, Torsten > The telecon ended after 1.5 hours and I'm summarizing our discussions > and decisions below: > > > 1) Adam's suggestion that datatype offsets have to be relative to MPI_BOTTOM > - Torsten creates a ticket to remove this sentence > > > 2) disp_unit should not be fixed (one can create one window for each) > - this issue was resolved and the comment will be ignored by Adam's > advice > > > 3) allocate_shared proposal with MPI_Win_lock_all(exclusive) > - remove MPI_Win_lock_all(exclusive) from the proposal and re-read > > > 4) ticket 300: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/300 > - Torsten will talk to Marc and report back > > > 5) ticket 283: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/283 > - Jim will bring a full proposal forward > > > 6) Adam suggested: p23, 6-7 Regarding status, we should either say that > > all fields are undefined (except for the error) or we should specify > > all values, e.g., what about values returned for MPI_GET_COUNT, > > MPI_GET_ELEMENTS, or MPI_TEST_CANCELLED? Replace "The values of the > > MPI_SOURCE and MPI_TAG fields are undefined." with "All other fields > > in status are undefined." -- Question: Would it be useful to set > > fields for count and get elements? > - Torsten will create a ticket to clarify that everything that is not > explicitly specified remains undefined (similar to I/O) > > Comments are welcome! > > Thanks & Best, > Torsten > > -- > bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- > Torsten Hoefler | Performance Modeling and Simulation Lead > Blue Waters Directorate | University of Illinois (UIUC) > 1205 W Clark Street | Urbana, IL, 61801 > NCSA Building | +01 (217) 244-7736 > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma > -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- Torsten Hoefler | Performance Modeling and Simulation Lead Blue Waters Directorate | University of Illinois (UIUC) 1205 W Clark Street | Urbana, IL, 61801 NCSA Building | +01 (217) 244-7736

1 0

Re: [Mpi3-rma] Next RMA Telecon
by Torsten Hoefler 09 Dec '11

09 Dec '11

Hello All, The telecon ended after 1.5 hours and I'm summarizing our discussions and decisions below: > 1) Adam's suggestion that datatype offsets have to be relative to MPI_BOTTOM - Torsten creates a ticket to remove this sentence > 2) disp_unit should not be fixed (one can create one window for each) - this issue was resolved and the comment will be ignored by Adam's advice > 3) allocate_shared proposal with MPI_Win_lock_all(exclusive) - remove MPI_Win_lock_all(exclusive) from the proposal and re-read > 4) ticket 300: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/300 - Torsten will talk to Marc and report back > 5) ticket 283: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/283 - Jim will bring a full proposal forward > 6) Adam suggested: p23, 6-7 Regarding status, we should either say that > all fields are undefined (except for the error) or we should specify > all values, e.g., what about values returned for MPI_GET_COUNT, > MPI_GET_ELEMENTS, or MPI_TEST_CANCELLED? Replace "The values of the > MPI_SOURCE and MPI_TAG fields are undefined." with "All other fields > in status are undefined." -- Question: Would it be useful to set > fields for count and get elements? - Torsten will create a ticket to clarify that everything that is not explicitly specified remains undefined (similar to I/O) Comments are welcome! Thanks & Best, Torsten -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- Torsten Hoefler | Performance Modeling and Simulation Lead Blue Waters Directorate | University of Illinois (UIUC) 1205 W Clark Street | Urbana, IL, 61801 NCSA Building | +01 (217) 244-7736

1 0

[Mpi3-rma] Fwd: Next RMA Telecon
by Rajeev Thakur 07 Dec '11

07 Dec '11

A reminder about this telecon on Friday at 2pm Central. Begin forwarded message: > From: Torsten Hoefler <htor(a)illinois.edu> > Date: November 27, 2011 1:14:07 PM CST > To: mpi3-rma(a)lists.mpi-forum.org > Subject: [Mpi3-rma] Next RMA Telecon > Reply-To: "MPI 3.0 Remote Memory Access working group" <mpi3-rma(a)lists.mpi-forum.org> > > Hello All, > > The doodle poll indicates that everybody can make it on Friday 12/9 > 2pm (I hope Brian can make it). We may need a bit more than 1 hour (it > would be good to discuss every item on the agenda, so please plan for > 1.5 hours if possible). The usual call-in information is (thanks to > Rajeev): > > Dial-in Number: 866-654-6744 > International Dial-in Number: 1-517-308-8226 > Participant Access code: 6086006 > > The current agenda draft includes: > > 1) Adam's suggestion that datatype offsets have to be relative to MPI_BOTTOM > 2) disp_unit should not be fixed (one can create one window for each) > 3) allocate_shared proposal with MPI_Win_lock_all(exclusive) > 4) ticket 300: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/300 > 5) ticket 283: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/283 > 6) Adam suggested: p23, 6-7 Regarding status, we should either say that > all fields are undefined (except for the error) or we should specify > all values, e.g., what about values returned for MPI_GET_COUNT, > MPI_GET_ELEMENTS, or MPI_TEST_CANCELLED? Replace "The values of the > MPI_SOURCE and MPI_TAG fields are undefined." with "All other fields > in status are undefined." -- Question: Would it be useful to set > fields for count and get elements? > > Additions are welcome anytime! > > Some of the questions come from Adam's review (see comments ticket 270). > I fixed several ticket 0 things in the proposal. Rajeev reviewed but > additional reviews are welcome! > > All the Best, > Torsten > > -- > bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- > Torsten Hoefler | Performance Modeling and Simulation Lead > Blue Waters Directorate | University of Illinois (UIUC) > 1205 W Clark Street | Urbana, IL, 61801 > NCSA Building | +01 (217) 244-7736 > _______________________________________________ > mpi3-rma mailing list > mpi3-rma(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

1 0