<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Hi Jeff,<BR>
<BR>
> inside of GA, I have to manually do everything that ARMCI_Malloc did<BR>> previously?<BR><BR>
yes the user has to. Do you think that is a bad idea?<BR><BR>
> Will it be possible for RMA to distinguish between segments which are<BR>> locally allocated as shared versus private? Presumably, it is much<BR><BR>
Certainly, the proposal mentions a memory attribute to inform the MPI implementation of any special memory like say preregistered memory.<BR>
<BR>
Thanks,<BR>
Vinod.<BR><BR>> Date: Mon, 8 Dec 2008 13:55:16 -0600<BR>> From: jeff.science@gmail.com<BR>> To: mpi3-rma@lists.mpi-forum.org<BR>> Subject: Re: [Mpi3-rma] FW: draft of a proposal for RMA interfaces<BR>> <BR>> I apologize in advance for potential noobiness...<BR>> <BR>> The GA user manual has an extensive discussion of the coupling between<BR>> GA, ARMCI and MA<BR>> (http://www.emsl.pnl.gov/docs/global/um/init.html#ma). If MPI3<BR>> one-sided communication replaces ARMCI as the messaging layer of GA,<BR>> what happens at the interface between these libraries? In particular,<BR>> in what way would the sentence "shared memory is used to store global<BR>> array data and is allocated by the Global Arrays run-time system<BR>> called ARMCI" change if "ARMCI" changes to "MPI3"?<BR>> <BR>> I imagine that it is not within the scope of MPI to start explicitly<BR>> managing local memory but does that mean that if I happen to get<BR>> inside of GA, I have to manually do everything that ARMCI_Malloc did<BR>> previously?<BR>> <BR>> Will it be possible for RMA to distinguish between segments which are<BR>> locally allocated as shared versus private? Presumably, it is much<BR>> harder to make RMA on shared segments thread safe and where one is<BR>> RMA-ing only between private segments then performance is increased in<BR>> the context of multithreading if the more rigorous locking procedure<BR>> used for the former is turned off.<BR>> <BR>> Thanks,<BR>> <BR>> Jeff<BR>> <BR>> On Mon, Dec 8, 2008 at 1:12 PM, Vinod tipparaju <tipparajuv@hotmail.com> wrote:<BR>> ><BR>> ><BR>> > As I am preparing the faq Rajeev suggested, please send me any more<BR>> > questions you want included.<BR>> > Thanks,<BR>> > Vinod.<BR>> ><BR>> > ________________________________<BR>> > From: thakur@mcs.anl.gov<BR>> > To: mpi3-rma@lists.mpi-forum.org<BR>> > Date: Mon, 8 Dec 2008 12:04:14 -0600<BR>> > Subject: [Mpi3-rma] FW: draft of a proposal for RMA interfaces<BR>> ><BR>> > Just resending this as a reminder. It would be good to have an FAQ that<BR>> > answers commonly asked questions.<BR>> ><BR>> > Rajeev<BR>> > ________________________________<BR>> > From: Rajeev Thakur [mailto:thakur@mcs.anl.gov]<BR>> > Sent: Sunday, October 19, 2008 6:43 PM<BR>> > To: 'MPI 3.0 Remote Memory Access working group'<BR>> > Subject: RE: [Mpi3-rma] draft of a proposal for RMA interfaces<BR>> ><BR>> > I think it would be good to add an FAQ section at the end, containing<BR>> > answers to questions that will be asked of any RMA proposal, such as<BR>> > non-cache-coherent, does it meet the needs of PGAS/Global Arrays, support<BR>> > for heterogeneous, how does the target know of completion, how does it<BR>> > interplay with existing RMA spec, etc. It will make sure that the proposal<BR>> > addresses those issues, that we ourselves are clear of the answers, and that<BR>> > they are not repeatedly raised at each meeting.<BR>> > Rajeev<BR>> ><BR>> >> Richard Graham wrote:<BR>> >><BR>> >>> Just to get discussion going again. Talking with several folks I have<BR>> >>> heard several concerns expressed about the proposal. I think it would<BR>> >>> be good if these (and others) could be raised on the list, so we can<BR>> >>> start discussion. We can continue this next week in Chicago, but<BR>> >>> Vinod will not be able to make this meeting, so an e-mail discussion<BR>> >>> will help.<BR>> >>><BR>> >>> Here are the issues I have hear of so far:<BR>> >>> - May not work well on current h/w that is not cache coherent, as it<BR>> >>> requires a remote thread in this case. I believe this is for the SX<BR>> >>> series of machines, but Jesper please correct me if I am wrong here.<BR>> >>> What would be an alternative approach that could provide expected<BR>> >>> performance on platforms that may require work on the remote end for<BR>> >>> RMA for correctness, and work well on platforms that do require very<BR>> >>> specific remote cache management (or other actions) for correctness ?<BR>> >>> - Concern about future high-end platforms, under that assumption that<BR>> >>> these will not be cache coherent (and will actually have caches – if<BR>> >>> they don't this is not a concern), and therefore this proposal is<BR>> >>> aimed at a short-lived technical capability.<BR>> >>> - What is missing ?<BR>> ><BR>> > _______________________________________________<BR>> > mpi3-rma mailing list<BR>> > mpi3-rma@lists.mpi-forum.org<BR>> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma<BR>> ><BR>> ><BR>> <BR>> <BR>> <BR>> -- <BR>> Jeff Hammond<BR>> The University of Chicago<BR>> http://home.uchicago.edu/~jhammond/<BR>> <BR>> _______________________________________________<BR>> mpi3-rma mailing list<BR>> mpi3-rma@lists.mpi-forum.org<BR>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma<BR><BR></body>
</html>