June 2008 - Mpich2-core - mailman3.cels.anl.gov

support for tag matching
by Darius Buntinas 22 Jul '08

22 Jul '08

Dave and I have been working with Guillaume's group to support madeleine as a netmod. Madeleine does tag matching, so this is a good time to look into how to, in general, support communication subsystems that do matching. It looks like we have a framework, but it requires changes in ch3. So I just want to run the changes by everyone and see if anyone has any comments or objections. If you're interested in the actual diffs, let me know, or you can look at the nmad branch in svn. Here are the ch3-related changes we made: Overriding send functions ------------------------- We added a check for an override for each of the MPID_*send() functions. E.g., for MPID_Send, we added this at the top: if (vc->mpid_send) { mpi_errno = vc->mpid_send(vc, buf, ...); goto fn_exit; } As you can see function pointers were added to the vc structure. MPIDI_CH3U_Recvq_FDU_or_AEP() ----------------------------- When the user posts a receive, this function is called and returns a request either from a matching unexpected message, or it allocates a new request and puts it on the posted recv queue. It used to take parameters only describing what is to be matched (i.e., rank, tag, context_id). We added parameters for comm, buf, count and datatype, so that these fields can be filled in by the function when it finds or allocates the request. In all places where this function was called this was done immediately afterwards anyway. Posted recv queue hooks ----------------------- CH3 already had hooks in the posted receive queue that a channel could implement which would be called when a request was enqueued or dequeued. We really didn't change anything in CH3 for this, so the rest of the text in this item describes what we did in nemesis. We implemented these hooks in nemesis to call an anysource handler if the recv is an anysource, otherwise to look up the vc and call a function pointer we added to the vc, vc->recv_posted(). Netmods can register anysource handler functions with nemesis. The nemesis anysource handler function calls each of the registered netmod anysource handlers. Please let me know if anyone has any comments on this, or if it's OK for me to commit these changes to the trunk. Thanks, -d

2 4

Orphaned files
by William Gropp 21 Jul '08

21 Jul '08

I'm cleaning up my CVS version of MPICH2, and I've found some files that don't seem to have made it into the SVN version. There's only one that looks really lost src/mpi/romio/test/write_all_test.c - from LANL Do we want this test (it has an LANL copyright, so the answer may be no)? I also have a pbs_work.tar.gz that contains groppmac:~/projects/software gropp$ tar ztf mpich2.old/src/pm/ pbs_work.tar.gz pbs_work/ pbs_work/tm.3 pbs_work/test_tm.c pbs_work/Makefile pbs_work/test_tm.cmd.o164 pbs_work/test_tm.cmd pbs_work/psched-api-report.ps Should these be in the pm directory anywhere? Bill William Gropp Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

6 8

BG/P patches
by Pavan Balaji 21 Jul '08

21 Jul '08

Hi all, Sorry about the delay in sending out the BG/P patches. I've placed them here: http://www.mcs.anl.gov/~balaji/projects/mpich2/bgp/r2. I've assigned a few patches to each person below. Can the below folks please confirm that you can go over them and make sure there are no problems integrating them into the trunk? The plan is to go over these and have a telecon around mid next week. The IBM folks didn't do a very good job in breaking up the diffs, so some of the patches are large; you'll probably need to break them up and try different parts separately. build.patch -- Bill datatype.patch -- Pavan dcmfd.patch -- Pavan debugger.patch -- Darius ignore.patch -- Pavan mpe.patch -- Anthony other.patch -- Rajeev test-build.patch -- Dave test-source.patch -- Dave A few things I noticed on a quick glance through the patches: 1. MPI_Aint vs. (void *). I remember that there was some discussion, but what was the conclusion? Can MPI_Aint be larger than (void *)? A large chunk of the patches assumes that these two can be different, so they introduce MPI_AINT_TO_VOID_PTR and friends to deal with such cases. 2. Some of the patches (e.g., debugger.patch, test-build.patch and test-source.patch) have a number of BG specific additions. These need to be pruned out in a way that IBM can still use it, but they will continue to be generic enough for other platforms. Thanks. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

10 52

Fwd: [Dave Goodell] sicortex failures
by Dave Goodell 09 Jul '08

09 Jul '08

Hello mpich2-core@, Would someone more familiar with the dataloop code than I am be willing to take a look at this bug? I can successfully reproduce this bug in the trunk of MPICH2 (although I have to effectively put his example inside of the library in order to coax it into compiling). -Dave Begin forwarded message: > From: David Gingold <david.gingold(a)sicortex.com> > Date: June 5, 2008 Jun 5 4:08:23 PM CDT > To: Dave Goodell <goodell(a)mcs.anl.gov>, Narayan Desai > <desai(a)mcs.anl.gov> > Subject: Re: [Dave Goodell] sicortex failures > > Dave and Narayan -- > > The code below demonstrates the trouble I'm having inside the > library with the dataloop code. > > Do you have someone around who could take a look at why it's > failing? You should be able to compile this against a generic > MPICH2 build, putting src/mpid/common/datatype in the include > path. With error checking enabled in the library, it generates an > assertion inside MPID_Segment_manipulate(). > > -dg > > .... > > #include <assert.h> > #include <stdlib.h> > #include <stdio.h> > #include <mpi.h> > > #include "mpid_dataloop.h" > > int MPID_Segment_init(const DLOOP_Buffer buf, > DLOOP_Count count, > DLOOP_Handle handle, > struct DLOOP_Segment *segp, > int hetero); > > void MPID_Segment_pack(struct DLOOP_Segment *segp, > DLOOP_Offset first, > DLOOP_Offset *lastp, > void *pack_buffer); > > int main(int argc, char *argv[]) > { > int ierr; > MPID_Segment segment; > MPI_Aint last; > int dis[2], blklens[2]; > MPI_Datatype type; > int send_buffer[60]; > int recv_buffer[60]; > > ierr = MPI_Init(&argc, &argv); > assert(ierr == MPI_SUCCESS); > > dis[0] = 0; > dis[1] = 20; > > blklens[0] = 0; > blklens[1] = 40; > > ierr = MPI_Type_indexed(2, blklens, dis, MPI_INT, &type); > assert(ierr == MPI_SUCCESS); > > ierr = MPI_Type_commit(&type); > assert(ierr == MPI_SUCCESS); > > ierr = MPID_Segment_init(send_buffer, 1, type, &segment, 0); > assert(ierr == MPI_SUCCESS); > > MPID_Segment_pack(&segment, 88, &last, recv_buffer); > > MPI_Finalize(); > return 0; > } >

4 12

nonblocking dynamic process routines
by Robert Latham 01 Jul '08

01 Jul '08

(kind of wanted to vet this in a friendly venue before poking around the forum..) Our student Bryan has observed a deficiency in MPI-2 dynamic process management routines. He's working on an MPI-base distributed hash table and wants to be able to MPI_Comm_accept when a new node joins the DHT. Meanwhile, nodes in the DHT are MPI_Irecv with ANY_SOURCE to do the neighbor message exchange that is the heart of the DHT algorithm. Without using threads, he can get pretty close except for one thing: there's no nonblocking MPI_Comm_accept. We were wondering if the forum considered and rejected a nonblocking MPI_Comm_accept, or if this is a new-to-the-forum idea? ==rob -- Rob Latham Mathematics and Computer Science Division A215 0178 EA2D B059 8CDF Argonne National Lab, IL USA B29D F333 664A 4280 315B

4 5

On leave today - Jun 18th
by Jayesh Krishna 18 Jun '08

18 Jun '08

Hi, I am not feeling well and will not be able to make it to office today. I am reachable via email and cell (571-451-7378). Regards, Jayesh

1 0

PMI v2
by William Gropp 17 Jun '08

17 Jun '08

I've updated both the PMI v2 client and wire protocol, incorporating Dave's comments. I'd like to finish this up and ask our partners for comments so that we can start implementing it (particularly the node attribute support for the SMP collectives). Are there any other changes of issues before we do that? Bill William Gropp Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

2 1

PMI v2 Client API
by William Gropp 02 Jun '08

02 Jun '08

I've put a draft of a new PMI client API up on the wiki at http:// wiki.mcs.anl.gov/mpich2/index.php/PMI_v2_API . I'd like to settle on this API soon and convert MPICH2 over to this API. In particular, it provides support for the hierarchical collectives and provides for extensibility to other attributes about the job and the process. BIll William Gropp Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

4 7