[hwloc-devel] Create success (hwloc git dev-574-gc6fa7b7)

Creating nightly hwloc snapshot git tarball was a success. Snapshot: hwloc dev-574-gc6fa7b7 Start time: Wed May 20 21:01:02 EDT 2015 End time: Wed May 20 21:02:48 EDT 2015 Your friendly daemon, Cyrador

Re: [OMPI devel] Open MPI collectives algorithm selection

George, first i'd like to amend my initial message. i previously wrote the same algo is used to parse rules per communicator size and per message size. this is true, but i missed the part where it is mandatory to define a rule for zero size message. consequently, a given message is either in

Re: [OMPI devel] smcuda higher exclusivity than anything else?

A few observations. 1. The smcuda btl is only built when --with-cuda is part of the configure line so folks who do not do this will not even have this btl and will never run into this issue. 2. The priority of the smcuda btl has been higher since Open MPI 1.7.5 (March 2014). The idea is that

Re: [OMPI devel] smcuda higher exclusivity than anything else?

Rolf - this doesn’t sound right to me. I assume that smcuda is only supposed to build if cuda support was found/requested, but if there are no cuda adapters, then I would have thought it should disqualify itself. Can we do something about this for 1.8.6? > On May 20, 2015, at 11:14 AM,

[OMPI devel] smcuda higher exclusivity than anything else?

I was making basic performance measurements on our machine after installing 1.8.5, the performance were looking bad. It turns out that the smcuda btl has a higher exclusivity than both vader and sm, even on machines with no nvidia adapters. Is there a strong reason why the default exclusivity

Re: [OMPI devel] Hang in IMB-RMA?

Hi Nathan, Not entirely sure it is related but I'm also seeing a hang at the end of Put_all_local with -mca pml ob1 -mca btl tcp,sm,self. It seems to have finished the test but doesn't proceed to the next one. When run alone, Put_all_local finishes fine. Also, I verified with master and I see

Re: [OMPI devel] Open MPI collectives algorithm selection

Each rule define an interval with the previous rule, and everything in an interval will be bound the the rule with the next message size. You cannot define a rule for a specific amount. Thus, the fact that the rules must be ordered by message size was done by design. Returning a NULL rule as

Re: [OMPI devel] Open MPI collectives algorithm selection

I could be wrong (George, please feel free to correct me), but I *think* this was the designed behavior. If you read Jelena's paper, http://www.open-mpi.org/papers/euro-pvmmpi-2006-collective-alg-selection/euro-pvmmpi-2006-collective-alg-selection.pdf you basically construct a new decision map

Re: [OMPI devel] Proposal: update Open MPI's version number and release process

Guys, you are way off-base here. This is why Jeff asked that we table this conversation until the devel meeting. As he and I discussed at length on the phone, your starting premise is incorrect. This entire thread stems from Jeff’s recent attempt to do a bisect search on the master. He hit

Re: [OMPI devel] Open MPI collectives algorithm selection

Howard, i made PR 593 https://github.com/open-mpi/ompi/pull/593 in order to fix this. George, could you please review this ? Cheers, Gilles On 5/20/2015 12:57 PM, Howard Pritchard wrote: HI Gilles, First a disclaimer - I do not know what the intended design was nor where the design

Re: [OMPI devel] Proposal: update Open MPI's version number and release process

On Tue, May 19, 2015 at 9:37 PM, Howard Pritchard wrote: > Pretty soon the developer will get trained to use the PR process, unless > they are that engineer I've yet to meet who always writes flawless code. I've never met that developer, either. However, I have met one

Re: [OMPI devel] Proposal: update Open MPI's version number and release process

On 20/05/15 14:37, Howard Pritchard wrote: > It would also be easy to trap the I-want-to-bypass-PR-because-I > know-what-I'm-doing-developer with a second level of protection. Just > set up a jenkins project that does a smoke test after ever commit to > master. If the smoke test fails, send a

Re: [OMPI devel] Proposal: update Open MPI's version number and release process

Hi Dave, > The other way to solve this issue would be to stop treating the master as > a general dumping ground for potentially unstable code where anyone can > just push any time they want. If we switched to using PRs for > (essentially) all code that goes into master as well, then we

Re: [OMPI devel] Open MPI collectives algorithm selection

HI Gilles, First a disclaimer - I do not know what the intended design was nor where the design document for this feature is located. However, I would certainly prefer that if the communicator size wasn't specifically specified in the rule file, a fall back do-no-harm algorithm would be