[Mpi3-rma] Updated MPI-3 RMA proposal 1

Barrett, Brian W bwbarre at sandia.gov
Thu Jun 17 09:38:46 CDT 2010

What did the greater forum think of the all_flush_all idea?  I have to agree with Keith - I think including the all_flush_all would result in death to the parts of the proposal I care about.  I don't dislike all_flush_all (I don't like it either), but I do think others will have a strong reaction to it, and if it kills the ability to fix real problems with the standard, it's harmful.

I know this is turning the question on it's head.  We're not looking for the "right" thing, or the "best" thing, or the "easiest to support ARMCI" thing - we're looking at what we can get the standards body to agree to.  Otherwise, we're going to have nothing from where we are today, which I can hope we all agree is worse than having proposal 1 without the all_flush_all.

To me, removing the lock restriction makes sense.  I don't think it would overly burden the MPI implementation, and has a fairly sane use case...


  Brian W. Barrett
  Scalable System Software Group
  Sandia National Laboratories
From: mpi3-rma-bounces at lists.mpi-forum.org [mpi3-rma-bounces at lists.mpi-forum.org] On Behalf Of Pavan Balaji [balaji at mcs.anl.gov]
Sent: Wednesday, June 16, 2010 8:48 PM
To: MPI 3.0 Remote Memory Access working group
Subject: Re: [Mpi3-rma] Updated MPI-3 RMA proposal 1

Btw, there was also some discussion on whether we can use MPI_Win_fence
to achieve the same thing, but the problem was that we couldn't use
flush/flushall in the Win_fence epoch; that was only relevant for the
lock/unlock epoch.

So, basically, we wanted something like Win_fence, but could be used
within the lock/unlock epoch.

  -- Pavan

On 06/16/2010 09:37 PM, Pavan Balaji wrote:
> Keith,
> We had some discussion on the point that allflushall was not one-sided
> like the rest of the passive target calls. But the consensus was that we
> were really looking for functionality -- if it doesn't match the rest of
> passive target, so be it. We can stop calling it "passive target" and
> rename it to something else, if it helps.
>   -- Pavan
> On 06/16/2010 09:09 PM, Underwood, Keith D wrote:
>>> This ship has sailed.  You're the only person who has voiced an objection to all_flush_all and numerous others
>>> have demonstrated at length why it is necessary.  I do not find the obsession with pure-passive target
>>> semantics to be a compelling reason to reject all_flush_all.
>> All_flush_all will further dissuade good implementations of passive-target semantics.  To my understanding, many implementations don't provide compliant passive-target semantics now and the introduction of all_flush_all will give another out to those implementations.  So, yeah, call me a purist, but it isn't JUST about doing API design that looks reasonable and has reasonable names.
>>>> Do we have the use cases for both of those and some attempt at
>>>> quantification of the performance advantage in some implementation?
>>> Yes.  I will not repeat the use case for all_flush_all since we have
>>> discussed that topic far too long already.  Somewhat else should
>>> present the multiple locks issue generically before I give the Global
>>> Arrays use case.
>> I have REPEATEDLY asked for a quantification of the advantage, and NOBODY has offered a quantitative discussion.  Lots of hand waving and discussion of challenges that are faced on BG, even an interesting implementation case given by Brian Smith, but he agreed that there would be a crossover where all_flush_all could be slower than flush_all + barrier, since there is an iteration that is involved.  And, right now, there is only one system I know of where there is an opportunity for an advantage: BG.  So, many of us CAN'T quantify the advantage.
>> Keith
>> _______________________________________________
>> mpi3-rma mailing list
>> mpi3-rma at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma

Pavan Balaji
mpi3-rma mailing list
mpi3-rma at lists.mpi-forum.org

More information about the mpiwg-rma mailing list