Re: [OMPI devel] autodetect broken

Heh. The list overrides the reply-to. :-) Agreed -- let's you, me, and Brian discuss off-list and let anyone who cares know what the final solution is that we come up with. FWIW, we've become quite fond of developing in mercurial branches and pushing them somewhere to share when you want

Re: [OMPI devel] OpenMPI, PLPA and Linux cpuset/cgroup support

I apologize for coming to this late - IU's email forwarding jammed up yesterday, so I'm only now getting around to reading the backlog. There has been some off-list discussion about advanced paffinity mappings/bindings. As I noted there, I am in the latter stages of completing a new mapper

Re: [OMPI devel] BTL receive callback

Hello Sebastian, Sounds like you are using the openib btl as a starting point, which is a good place to start. I am curious if you are indeed using a new interconnect (new hardware and protocol) or if it is requirements of the 3D-torus network that are not addressed by the openib btl that are

Re: [OMPI devel] OpenMPI, PLPA and Linux cpuset/cgroup support

On Wed, Jul 22, 2009 at 19:24, Jeff Squyres wrote: > Bert -- is this functionality something we'd want to incorporate into PLPA? What functionality? The complete libcpuset or just the 'get me the cpuset mask of this task'? I don't think its good if we duplicate the whole

Re: [OMPI devel] autodetect broken

On Jul 22, 2009, at 10:55 AM, Brian W. Barrett wrote: The current autodetect implementation seems like the wrong approach to me. I'm rather unhappy the base functionality was hacked up like it was without any advanced notice or questions about original design intent. We seem to have a set

Re: [OMPI devel] OpenMPI, PLPA and Linux cpuset/cgroup support

Bert -- is this functionality something we'd want to incorporate into PLPA? On Jul 22, 2009, at 1:13 PM, Bert Wesarg wrote: On Wed, Jul 22, 2009 at 18:55, Bert Wesarg wrote: > I does not know any C interface to get a tasks cpuset mask (ok, > libcpuset Just an

Re: [OMPI devel] OpenMPI, PLPA and Linux cpuset/cgroup support

On Jul 22, 2009, at 11:17 AM, Sylvain Jeaugey wrote: I'm interested in joining the effort, since we will likely have the same problem with SLURM's cpuset support. Ok. > But as to why it's getting EINVAL, that could be wonky. We might want to > take this to the PLPA list and have you

Re: [OMPI devel] OpenMPI, PLPA and Linux cpuset/cgroup support

On Wed, Jul 22, 2009 at 18:55, Bert Wesarg wrote: > I does not know any C interface to get a tasks cpuset mask (ok, > libcpuset Just an amendment to give the url to the libcpuset homepage: http://oss.sgi.com/projects/cpusets/ > > Bert >> >> Sylvain >>

Re: [OMPI devel] OpenMPI, PLPA and Linux cpuset/cgroup support

On Wed, Jul 22, 2009 at 17:17, Sylvain Jeaugey wrote: > Hi Jeff, > > I'm interested in joining the effort, since we will likely have the same > problem with SLURM's cpuset support. > > On Wed, 22 Jul 2009, Jeff Squyres wrote: > >> But as to why it's getting EINVAL, that

Re: [OMPI devel] OpenMPI, PLPA and Linux cpuset/cgroup support

Hi Jeff, I'm interested in joining the effort, since we will likely have the same problem with SLURM's cpuset support. On Wed, 22 Jul 2009, Jeff Squyres wrote: But as to why it's getting EINVAL, that could be wonky. We might want to take this to the PLPA list and have you run some small,

Re: [OMPI devel] pb with --enable-mpi-threads --enable-progress-threads options

***Progress thread support currently does not work, and may never be fully implemented. If you remove that configure option, it should work.* ** *I'm pretty sure we only left that option so developers could play at fixing it, though I don't know of anyone actually making the attempt at the

Re: [OMPI devel] OpenMPI, PLPA and Linux cpuset/cgroup support

I'm the "primary PLPA" guy that Ralph referred to, and I was on vacation last week -- sorry for missing all the chatter. Based on your mails, it looks like you're out this week -- so little will likely occur. I'm at the MPI Forum standards meeting next week, so my replies to email will be

Re: [OMPI devel] autodetect broken

The current autodetect implementation seems like the wrong approach to me. I'm rather unhappy the base functionality was hacked up like it was without any advanced notice or questions about original design intent. We seem to have a set of base functions which are now more unreadable than

Re: [OMPI devel] default btl eager_limit

Jeff Squyres wrote: Just to follow up for the web archives -- we discussed this on the teleconf yesterday and decided that the assert()'s were not the way to go. Brian was going to hack up a quick check at the end of OB1 add_procs that checks each btl's eager_limit, etc. Terry would expand

Re: [OMPI devel] default btl eager_limit

Just to follow up for the web archives -- we discussed this on the teleconf yesterday and decided that the assert()'s were not the way to go. Brian was going to hack up a quick check at the end of OB1 add_procs that checks each btl's eager_limit, etc. Terry would expand this to cover dr

[OMPI devel] pb with --enable-mpi-threads --enable-progress-threads options

Hi, I have added the two following options: --enable-mpi-threads --enable-progress-threads in configure step of openmpi-1.3.3. After install, mpirun command doesn't work on a very simple mpi program. There is a dead lock and program is not executed. Bernard

Re: [OMPI devel] fortran MPI_COMPLEX datatype broken

A little more data... ompi_datatype_module.c:442 says #if 0 /* XXX TODO The following may be deleted, both CXX and F77/F90 complex types are statically set up */ ...followed by code to initialize ompi_mpi_cplx (i.e., MPI_COMPLEX). (another TODO!!) But ompi_mpi_cplex is setup with: