<!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>