Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] [OMPI svn] svn:open-mpi r25476
From: George Bosilca (bosilca_at_[hidden])
Date: 2011-11-18 12:13:37


On Nov 18, 2011, at 07:49 , Ralph Castain wrote:

> That's a condition which should never be reached, but just to be safe, I have added a "bozo check" that will cause the routine to error out with a message if that situation occurs. I have tried everything - hostfile, dash-host, bizarre combinations of hosts, etc. - and been unable to replicate your described problem.

What I see is that the impossible happened. Every run, consistently and only after the commit r25476. Anyway, this is now fixed by commit r25492. Feel free to remove the bozo check, it sounds very weird to expose that to our users.

>> Moreover, reading the comments in this file, FREAK me out, as apparently each mapper is allowed to have a different behavior…
>
> Not sure why that would "freak" you out as this has always been the case. Since the project started, we have allowed the user to separately specify mapping, ranking, and binding algorithms so they can reach a wide range of placement patterns. We have also allowed individual mappers to either use the base functions, or to completely ignore them - e.g., the rank-file mapper always ignored the base and just did things its own way.

You're twisting what I said. The comment implies that the mappers don't have a consistent behavior, some being allowed to update some lists while others are not. This is what freak me out, not that they map the processes differently.

> None of that is new or changed. The only thing that changed is that we extended the range of resource types over which the user can exercise control. Instead of just slots and nodes, it now includes cores, hwthreads, and other strange beasts. So the number of possible combinations is much, much greater than before.

Sure, I read that in the RFC!

> Don't blame me for the added complexity. I argued against some of this as I'm convinced it will rarely, if ever, be used - but I'm told this is what the user community wants, and so that is what I created.

Again, this was clearly specified in the RFC, and thoroughly discussed in the community. The entire discussion can be found, as usual, in the thread started by the RFC. Absolutely, no issues here.

  george.

> What I did, as I stated, was to ensure that the previous minimal option behavior remains the same - i.e., default behavior and simple options like -bynode result in the same patterns as before. So only gluttons for punishment get exposed to the added complexity.

  george.