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. 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. ;-) -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
