[mpiwg-rma] need MPI_MODE_NOSTORE (and MPI_MODE_NOLOAD) for passive-target

[Jeff Hammond]

MPI_MODE_NOFLUSHALL might allow an implementation to avoid using state
to track active target ranks.  For example, if I want to optimize the
sparse-rank-list case of FLUSH_ALL, I might keep track of all the
ranks that I target so I can flush them rather than flushing all ranks
for the window (which is sufficient but not necessary).  If the user
intends to do this above MPI or otherwise does not need FLUSH_ALL,
then the implementation can skip this state and always flush the
remote rank in FLUSH.  I recognize that an implementation might use
that active target list to make FLUSH a no-op, but this seems like a
much less important optimization since it is reasonable to assume a
use case where FLUSH is used when necessary.

Jeff

On Mon, Oct 21, 2013 at 12:06 PM, Jim Dinan <james.dinan at gmail.com> wrote:
> Sounds reasonable to me.  Are there other assertions that would be useful to
> consider?  I can't think of a use case, but MPI_MODE_NOFLUSH could be given
> in conventional lock/unlock epochs.
>
>  ~Jim.
>
>
> On Mon, Oct 21, 2013 at 12:30 PM, Jeff Hammond <jeff.science at gmail.com>
> wrote:
>>
>> Now that we allow both load-store and Put/Get within an epoch in the
>> UNIFIED model, we should enable the MPI_MODE_NOSTORE as well as the
>> new assertion MPI_MODE_NOLOAD for MPI_WIN_LOCK(_ALL) in MPI 3.0 \S
>> 11.5.5.
>>
>> This suggestion was inspired by Brian's comment about NIC-cached
>> atomics.  I presume that implementation can relax the consistent
>> enforced if these assertions are used.
>>
>> This is not necessarily a complete statement of the issues at hand but
>> I presume we can get there rather quickly if people think about this.
>>
>> Jeff
>>
>> --
>> Jeff Hammond
>> jeff.science at gmail.com
>> _______________________________________________
>> mpiwg-rma mailing list
>> mpiwg-rma at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma
>
>
>
> _______________________________________________
> mpiwg-rma mailing list
> mpiwg-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma



-- 
Jeff Hammond
jeff.science at gmail.com