<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [Mpi3-rma] draft of a proposal for RMA interfaces</TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6000.16735" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=608520218-08122008><FONT face=Arial 
color=#0000ff size=2>Just resending this as a reminder. It would be good to have 
an FAQ that answers commonly asked questions.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=608520218-08122008><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=608520218-08122008><FONT face=Arial 
color=#0000ff size=2>Rajeev</FONT></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Rajeev Thakur [mailto:thakur@mcs.anl.gov] 
<BR><B>Sent:</B> Sunday, October 19, 2008 6:43 PM<BR><B>To:</B> 'MPI 3.0 Remote 
Memory Access working group'<BR><B>Subject:</B> RE: [Mpi3-rma] draft of a 
proposal for RMA interfaces<BR></FONT><BR></DIV>
<DIV></DIV><!-- Converted from text/plain format -->
<P><FONT size=2>I think it would be good to add an FAQ section at the end, 
containing answers to questions that will be asked of any RMA proposal, such as 
non-cache-coherent, does it meet the needs of PGAS/Global Arrays, support for 
heterogeneous, how does the target know of completion, how does it interplay 
with existing RMA spec, etc. It will make sure that the proposal addresses those 
issues, that we ourselves are clear of the answers, and that they are not 
repeatedly raised at each meeting.</FONT></P>
<P><FONT size=2>Rajeev </FONT></P><BR>
<P><FONT size=2>> Richard Graham wrote:</FONT> <BR><FONT size=2>></FONT> 
<BR><FONT size=2>>> Just to get discussion going again. Talking with 
several folks I have </FONT><BR><FONT size=2>>> heard several concerns 
expressed about the proposal. I think it would </FONT><BR><FONT size=2>>> 
be good if these (and others) could be raised on the list, so we can 
</FONT><BR><FONT size=2>>> start discussion. We can continue this next 
week in Chicago, but </FONT><BR><FONT size=2>>> Vinod will not be able to 
make this meeting, so an e-mail discussion </FONT><BR><FONT size=2>>> will 
help.</FONT> <BR><FONT size=2>>></FONT> <BR><FONT size=2>>> Here are 
the issues I have hear of so far:</FONT> <BR><FONT size=2>>> - May not 
work well on current h/w that is not cache coherent, as it </FONT><BR><FONT 
size=2>>> requires a remote thread in this case. I believe this is for the 
SX </FONT><BR><FONT size=2>>> series of machines, but Jesper please 
correct me if I am wrong here. </FONT><BR><FONT size=2>>> What would be an 
alternative approach that could provide expected </FONT><BR><FONT 
size=2>>> performance on platforms that may require work on the remote end 
for </FONT><BR><FONT size=2>>> RMA for correctness, and work well on 
platforms that do require very </FONT><BR><FONT size=2>>> specific remote 
cache management (or other actions) for correctness ?</FONT> <BR><FONT 
size=2>>> - Concern about future high-end platforms, under that assumption 
that </FONT><BR><FONT size=2>>> these will not be cache coherent (and will 
actually have caches – if </FONT><BR><FONT size=2>>> they don’t this is 
not a concern), and therefore this proposal is </FONT><BR><FONT size=2>>> 
aimed at a short-lived technical capability.</FONT> <BR><FONT size=2>>> - 
What is missing ?</FONT> </P></BODY></HTML>