Jeff, If I can't have that type of fine level control, it means that any new development we do will have to replicate this functionality. While most users don't need this sort of capabilities, it is essential for experimenting with some algorithmic ideas as new code is being developed. We actually plan to bring in some new capabilities into the code base soon, for which we need this functionality. If you don't want to enhance it to support new hardware capabilities, then please leave it in, and those that need such h/w support can extend this.
Rich On 4/15/10 6:00 PM, "Jeff Squyres (jsquyres)" <jsquy...@cisco.com> wrote: WHAT: Deprecate the "rankfile" component in the v1.5 series; remove it in the 1.7 series WHY: It's old, creaky, and difficult to maintain. It'll require maintenance someday soon, when we support hardware / hyperthreads in OMPI. WHERE: svn rm orte/mca/rmaps/rank_file WHEN: Deprecate in 1.5, remove in 1.7. TIMEOUT: Teleconf on Tue, 27 April 2010 ----- Now that we have nice paffinity binding options, can we deprecate rankfile in the 1.5 series and remove it in 1.7? I only ask because it's kind of a pain to maintain. It's not a huge deal, but Ralph and I were talking about another paffinity issue today and we both groaned at the prospect of extending rank file to support hyperthreads (and/or boards). Perhaps it should just go away...? Pro: less maintenance, especially since the original developers no longer maintain it Con: it's the only way to have completely custom affinity bindings (i.e., outside of our pre-constructed "bind to socket", "bind to core", etc. options). ...do any other MPI's offer completely custom binding options? I.e., do any real users care? -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ _______________________________________________ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
