[Mpi3-rma] Alternative Proposal for Shared Memory Support

[Bronis R. de Supinski]

Torsten:

What happens if the processes do not have shared physical
memory? Is it just that physical shared memory is used
when possible? What if multple nodes are included in comm?
Will each node use shared memory? That seems fairly
reasonable. Overall, I think this proposal is good. I do
think a number of details have to be worked out before
it is ready but I agree that discussing it at a Forum
meeting is the way to go.

Perhaps we could request a joint RMA/Hybrid WG session
to discuss it? I think it is a mistake to cover it just
within one group or the other.

Bronis


On Tue, 15 Mar 2011, Torsten Hoefler wrote:

> Hello all,
>
> I apologize for the cross-post but this is of interest to two groups. I
> have an alternative proposal for the shared memory support. I believe
> that it would naturally integrate into the One Sided chapter as a
> special type of window. This would save some additional function calls
> and seems to make semantical definitions tighter and the whole standard
> more orthogonal. Thanks to Brian, Bill, Marc, and Ron for preliminary
> discussions of the idea.
>
> Here is the proposed new call:
>
> MPI_Win_allocate_shared(size, info, comm, *baseptr, *win);
>
> This would create a special window in the "unified" model which is
> referencing the same physical memory on all processes in a shared memory
> domain. The group of processes that share memory can be queried with
> MPI_Win_get_group() and a new MPI_WIN_FLAVOR_SHARED would be added as
> window type.
>
> The whole concept is even mightier because one could now support NCC
> shared memory (I remember than Hubert mentioned that in one of the
> discussions) if we would allow the "separate" window type for it.
> However, this seems to introduce all kinds of complex interactions
> (e.g., does everybody logically have it's own public copy of the *same*
> memory). I'm not proposing this at this point but it might be worth
> a discussion!
>
> This would make the new proposed calls "MPI_COMM_SHM_FREE(shm)" and
> "MPI_SHM_FENCE" superfluous and would enable all synchronizations and
> portable (!!) atomic operations that we defined in the RMA chapter
> immediately. This would also remove the need to have a special
> MPI_COMM_SHM as required in the hybrid proposal.
>
> Any comments are welcome. I can talk about this at the next meeting
> (most likely in the RMA group on Tuesday).
>
> All the Best,
>  Torsten
>
> -- 
> bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ -----
> Torsten Hoefler         | Performance Modeling and Simulation Lead
> Blue Waters Directorate | University of Illinois (UIUC)
> 1205 W Clark Street     | Urbana, IL, 61801
> NCSA Building           | +01 (217) 244-7736
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma
>