This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
I am putting it back.
> -----Original Message-----
> From: Terry.Dontje_at_[hidden] [mailto:Terry.Dontje_at_[hidden]]
> Sent: Monday, March 31, 2008 2:59 PM
> To: Open MPI Developers
> Cc: Lenny Verkhovsky; Sharon Melamed
> Subject: Re: [OMPI devel] RMAPS rank_file component patch and
> modifications for review
> Jeff Squyres wrote:
> > On Mar 27, 2008, at 8:02 AM, Lenny Verkhovsky wrote:
> >>> - I don't think we can delete the MCA param ompi_paffinity_alone;
> >>> exists in the v1.2 series and has historical precedent.
> >> It will not be deleted,
> >> It will just use the same infrastructure ( slot_list parameter and
> >> opal_base functions ). It will be transparent for the user.
> >> User have 3 ways to setup it
> >> 1. mca opal_paffinity_alone 1
> >> This will set paffinity as it did before
> >> 2. mca opal_paffinity_slot_list "slot_list"
> >> Used to define slots that will be used for all ranks on all
> >> nodes.
> >> 3. mca rmaps_rank_file_path rankfile
> >> Assigning ranks to CPUs according to the file
> > I don't see the MCA parameter "mpi_paffinity_alone" anymore:
> > -----
> > [4:54] svbu-mpi:~/svn/ompi2 % ompi_info --param all all | grep
> > paffinity_alone
> > MCA opal: parameter "opal_paffinity_alone" (current
> > value: "0")
> > [4:54] svbu-mpi:~/svn/ompi2 %
> > -----
> > My point is that I don't think we should delete this parameter;
> > is historical precedence for it (and it has been documented on the
> > page for a long, long time). Perhaps it can now simply be a synonym
> > for opal_paffinity_alone (registered in the MPI layer, not opal).
> I agree with Jeff on the above. This would cause a lot of busy work
> our customers and internal setups.