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.
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.dontje_at_[hidden]
> devel mailing list