<div dir="ltr">All these MPI_Win_X stuff has no benefit in practice. why do you care ? no one<div>is using it, mp.</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/10/14 Jeff Hammond <span dir="ltr"><<a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, Oct 14, 2013 at 4:40 PM, Barrett, Brian W <<a href="mailto:bwbarre@sandia.gov">bwbarre@sandia.gov</a>> wrote:<br>

> On 10/12/13 1:49 PM, "Jeff Hammond" <<a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a>> wrote:<br>
><br>
>>Pavan told me that (in MPICH) MPI_Win_allocate is way better than<br>
>>MPI_Win_create because the former allocates the shared memory<br>
>>business.  It was implied that the latter requires more work within<br>
>>the node. (I thought mmap could do the same magic on existing<br>
>>allocations, but that's not really the point here.)<br>
><br>
> Mmap unfortunately does no such magic.  In OMPI, the current design will<br>
> use XPMEM to do that magic for WIN_CREATE, or only create shared memory<br>
> windows when using MPI_WIN_ALLOCATE{_SHARED}.<br>
<br>
</div>Okay, it seems Blue Gene/Q is the only awesome machine that allows for<br>
interprocess load-store for free (and not even "for 'free'").<br>
<div class="im"><br>
>>But within a node, what's even better than a window allocated with<br>
>>MPI_Win_allocate is a window allowed with MPI_Win_allocate_shared,<br>
>>since the latter permits load-store.  Then I wondered if it would be<br>
>>possible to have both (1) direct load-store access within a node and<br>
>>(2) scalable metadata for windows spanning many nodes.<br>
>><br>
>>I can get (1) but not (2) by using MPI_Win_allocate_shared and then<br>
>>dropping a second window for the internode part on top of these using<br>
>>MPI_Win_create.  Of course, I can get (2) but not (1) using<br>
>>MPI_Win_allocate.<br>
>><br>
>>I propose that it be possible to get (1) and (2) by allowing<br>
>>MPI_Win_shared_query to return pointers to shared memory within a node<br>
>>even if the window has MPI_WIN_CREATE_FLAVOR=MPI_WIN_FLAVOR_ALLOCATE.<br>
>>When the input argument rank to MPI_Win_shared_query corresponds to<br>
>>memory that is not accessible by load-store, the out arguments size<br>
>>and baseptr are 0 and NULL, respectively.<br>
><br>
> I like the concept and can see it's usefulness.  One concern I have is<br>
> that there is some overhead when doing native RDMA implementations of<br>
> windows if I'm combining that with shared memory semantics.  For example,<br>
> imagine a network that provides fast atomics by having a nic-side cache<br>
> that's non-coherent with e processor caches.  I can flush that cache at<br>
> the right times with the current interface, but that penalty is pretty<br>
> small because "the right times" is pretty small.  With two levels of<br>
> communication, the number of times that cache needs to be flushed is<br>
> increased, adding some small amount of overhead.<br>
<br>
</div>How is this non-coherent NIC-side cache consistent with the UNIFIED<br>
model, which is the only case in which shared-memory window semantics<br>
are defined?  I am looking for a shortcut to the behavior of<br>
overlapping windows where one of the windows is a shared-memory<br>
window, so this is constrained to the UNIFIED model.<br>
<div class="im"><br>
> I think that overhead's ok if we have a way to request that specific<br>
> behavior, rather than asking after the fact if you can get shared pointers<br>
> out of a multi-node window.<br>
<br>
</div>If there is a need to specify this, then an info key is sufficient,<br>
no?  I would imagine some implementations provide it at no additional<br>
cost and thus don't need the info key.<br>
<div class="im"><br>
>>The non-scalable use of this feature would be to loop over all ranks<br>
>>in the group associated with the window and test for baseptr!=NULL,<br>
>>while the scalable use would presumably utilize MPI_Comm_split_type,<br>
>>MPI_Comm_group and MPI_Group_translate_ranks to determine the list of<br>
>>ranks corresponding to the node, hence the ones that might permit<br>
>>direct access.<br>
><br>
> This brings up another questionŠ  0 is already a valid size.  What do we<br>
> do with FORTRAN for your proposed case?<br>
<br>
</div>I don't see what size has to do with this, but Pavan also pointed out<br>
that Fortran is a problem.  Thus, my second suggestion would become a<br>
requirement for usage, i.e. the user is only permitted to use<br>
win_shared_query on ranks in the communicator returned by<br>
MPI_Comm_split_type(type=SHARED).<br>
<div class="im HOEnZb"><br>
Jeff<br>
<br>
--<br>
Jeff Hammond<br>
<a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a><br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
mpiwg-rma mailing list<br>
<a href="mailto:mpiwg-rma@lists.mpi-forum.org">mpiwg-rma@lists.mpi-forum.org</a><br>
<a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma" target="_blank">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-rma</a></div></div></blockquote></div><br></div>