To be clear, I wasn't implying anyone would intentionally break rank_file. However, it is rarely (if ever?) tested before we release - AFAIK, none of the MTT tests run by the community test this feature. Thus, it inevitably breaks without detection as changes are made elsewhere in the system. We typically don't know it is broken until someone complains about it, which usually is several months after the release.
So I'll stand by my "self deprecate" comment. It has been the history of this feature, and I don't see anything changing to improve that situation. Now if you implement a replacement... :-) On Apr 16, 2010, at 5:08 AM, Terry Dontje wrote: > Jeff Squyres wrote: >> >> On Apr 16, 2010, at 6:43 AM, Terry Dontje wrote: >> >> >>> If you are suggesting that you will make code that breaks a current >>> rankfile feature, note I am not talking about adding a new feature that >>> isn't supported by rankfile but something that used to work, then I think >>> you are acting in poor form. At a minimum you should at least give the >>> community a heads up that you are borking a feature. >>> >> >> Er... no. >> >> There is nothing nefarious going on here. Ralph and I were just chatting >> yesterday about some process affinity issues and the topic of rank_file came >> up (again). Remember that rank_file was a "throw over the wall" kind of >> code contribution and has historically been difficult to maintain. Neither >> of us were excited at the prospect of adding hyperthreading support (once >> hwloc is finally released -- unfortunately, it's blocking on me, at the >> moment...) and also having to extend rank file to support it. >> >> I asked Ralph if we should deprecate rank_file since the other binding >> options are available. He assumed (correctly, it turns out) that no one >> would go for that. But I figured I'd ask anyway. >> >> I think all Ralph is saying is that we're (I'm) likely to add hyperthreading >> support in the not-distant future (and maybe Oracle will add support for >> boards). This work is not likely to *break* rank_file, but neither of us >> are excited about extending rank_file to support hyperthreading. If no one >> else steps up to extend it, then it may become obsolete over time because it >> doesn't support the things that people want. >> >> > I am ok with the above. >> Terry -- perhaps it's time to resurrect the new processor affinity proposal >> that you've been promising me for many months. If rank_file were replaced >> with Something Better, I'd certainly be happy. ;-) >> >> > Can we then have Ralph implement it :-)... That was a joke Ralph!!! > > > -- > <Mail Attachment.gif> > Terry D. Dontje | Principal Software Engineer > Developer Tools Engineering | +1.650.633.7054 > Oracle - Performance Technologies > 95 Network Drive, Burlington, MA 01803 > Email terry.don...@oracle.com > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
