This is cool stuff! I have no doubt that it could be used to implement the
current chapter. However, as you say, it is a future operating system. My
concern is that the current draft is hostile toward current operating systems.
By 'arbitrary addresses' I mean the following: Any process is allowed to
perform get/put operations on any memory location in another process. This is
the most general case and it is very non-portable. UNIX certainly doesn't let
you do this sort of thing normally. MPPs are sort of special because a lot of
them don't support timesharing and so you get to do fun things like mess around
with remote memory locations. Does Puma support timesharing on MPP nodes?
At any right, I claim that my proposal imposes zero additional copying. The
'mapping' mechanism is really just a way to establish a naming convention for
remote addresses, and provides enough information to allow for fast
implementations. For example, on a SMP, the buffer that you get from
MPI_SHMALLOC() will be a real shared region, and by calling MPI_PUT() you can
store your data directly into the memory of the receiving process. On a
distributed MPP, the communicator created by MPI_SHMALLOC() will contain the
'real' address of the remote buffer and again MPI_PUT() can place the data
directly into the remote memory.
-- Eric Salo Silicon Graphics Inc. "Do you know what the (415)390-2998 2011 N. Shoreline Blvd, 7L-802 last Xon said, just firstname.lastname@example.org Mountain View, CA 94043-1389 before he died?"