[hwloc-devel] Create success (hwloc git 1.7.2-26-gaaaf369)

Creating nightly hwloc snapshot git tarball was a success. Snapshot: hwloc 1.7.2-26-gaaaf369 Start time: Wed Apr 23 21:03:25 EDT 2014 End time: Wed Apr 23 21:05:43 EDT 2014 Your friendly daemon, Cyrador

[hwloc-devel] Create success (hwloc git dev-156-g7489287)

Creating nightly hwloc snapshot git tarball was a success. Snapshot: hwloc dev-156-g7489287 Start time: Wed Apr 23 21:01:01 EDT 2014 End time: Wed Apr 23 21:03:24 EDT 2014 Your friendly daemon, Cyrador

Re: [hwloc-devel] PATCH: Mark fd as close-on-exec

On Wed, Apr 23, 2014 at 4:14 PM, Brice Goglin wrote: > This code is only built on Linux Yes, of course! I neglected to look at the name of the file in question. No guard is needed for even my oldest Linux systems. -Paul -- Paul H. Hargrove

Re: [OMPI devel] Bug report: non-blocking allreduce with user-defined operation gives segfault

Rupert, You are right, the code of any non-blocking reduce is not built with user-level op in mind. However, I'm not sure about your patch. One reason is that ompi_3buff is doing target = source1 op source2 while ompi_2buf is doing target op= source (notice the op=) Thus you can't replace

Re: [hwloc-devel] PATCH: Mark fd as close-on-exec

This code is only built on Linux so I am not sure we're more portable than OMPI here. The oldest Linux we've tested bwloc on is likely your machines ;) Brice On 24 avril 2014 00:48:46 UTC+02:00, Paul Hargrove wrote: >Since I suspect hwloc may run on *more* platforms than

Re: [hwloc-devel] PATCH: Mark fd as close-on-exec

Currently, POSIX defines exactly one flag accessed via F_GETFD/F_SETFD and that is FD_CLOEXEC. However, it does not prohibit a conforming implementation from defining additional bits. So, a portable program should assume other bits may be set and try to preserve them. Quoting from section 3.14

[hwloc-devel] PATCH: Mark fd as close-on-exec

Any objections to this patch? In OMPI, we're seeing this fd leak into child processes. diff --git a/src/topology-linux.c b/src/topology-linux.c index e934d4c..8c5fba1 100644 --- a/src/topology-linux.c +++ b/src/topology-linux.c @@ -4601,6 +4601,13 @@ hwloc_linux_component_instantiate(struct

Re: [OMPI devel] openmpi and XRC API from ofed-3.12

As maintainer of a different communications library over Verbs I'd like to ask: Where can one find information on the new APIs and their use? -Paul On Wed, Apr 23, 2014 at 7:01 AM, Nathan Hjelm wrote: > Yes, we plan to fix support for XRC due to the changes in 3.12. It will

[OMPI devel] Bug report: non-blocking allreduce with user-defined operation gives segfault

Hello devel list I've been trying to use a non-blocking MPI_Iallreduce in a CFD application I'm working on, but it kept segfaulting on me. I have reduced it to a simple test case - see the gist here for the full code https://gist.github.com/rupertnash/1182 build and run with:

Re: [OMPI devel] openmpi and XRC API from ofed-3.12

Yes, we plan to fix support for XRC due to the changes in 3.12. It will probably not happen before 1.8.2 though. -Nathan On Wed, Apr 23, 2014 at 02:58:49PM +0200, Piotr Lesnicki wrote: > Hi, > > In OFED-3.12 the API for XRC has changed. I did not find > corresponding changes in Open MPI: for

[OMPI devel] openmpi and XRC API from ofed-3.12

Hi, In OFED-3.12 the API for XRC has changed. I did not find corresponding changes in Open MPI: for example the function 'ibv_create_xrc_rcv_qp()' queried in openmpi configure script no longer exists in ofed-3.12-rc1. Are there any plans to support the new XRC API ? -- Piotr

Re: [OMPI devel] coll/tuned MPI_Bcast can crash or silently fail when using distinct datatypes across tasks

my bad :-( this has just been fixed Gilles On 2014/04/23 14:55, Nathan Hjelm wrote: > The ompi_datatype_flatten.c file appears to be missing. Let me know once > it is committed and I will take a look. I will see if I can write the > RMA code using it over the next week or so. >

Re: [OMPI devel] coll/tuned MPI_Bcast can crash or silently fail when using distinct datatypes across tasks

The ompi_datatype_flatten.c file appears to be missing. Let me know once it is committed and I will take a look. I will see if I can write the RMA code using it over the next week or so. -Nathan On Wed, Apr 23, 2014 at 02:43:12PM +0900, Gilles Gouaillardet wrote: > Nathan, > > i uploaded this

Re: [OMPI devel] coll/tuned MPI_Bcast can crash or silently fail when using distinct datatypes across tasks

George, i am sorry i cannot see how flatten datatype can be helpful here :-( in this example, the master must broadcast a long vector. this datatype is contiguous so the flatten'ed datatype *is* the type provided by the MPI application. how would pipelining happen in this case (e.g. who has to

Re: [OMPI devel] coll/tuned MPI_Bcast can crash or silently fail when using distinct datatypes across tasks

Nathan, i uploaded this part to github : https://github.com/ggouaillardet/ompi-svn-mirror/tree/flatten-datatype you really need to check the last commit : https://github.com/ggouaillardet/ompi-svn-mirror/commit/a8d014c6f144fa5732bdd25f8b6b05b07ea8 please consider this as experimental and

Re: [OMPI devel] Issues with MPI_Add_error_class()

Both these issues are fixed in the trunk and are scheduled for the 1.8. The commit you need to check is r28584 and the corresponding ticket is https://svn.open-mpi.org/trac/ompi/ticket/4554 George. On Mon, Apr 21, 2014 at 8:45 AM, Lisandro Dalcin wrote: > It seems the