I put back more code changes and refreshed the RFC a little. So, if you
want a latest/greatest copy, here is the (slightly) amended RFC. Thanks
for the positive feedback so far, but more scrutiny is appreciated!
Title: RFC: Fragmented sm Allocations
RFC: Fragmented sm Allocations
WHAT: D
Unfortunately, I have to throw the flag in the v1.3 release. :-(
I ran ~16k tests via MTT yesterday on the rc5 and rc6 tarballs. I
found the following:
Found test runs: 15962
Passed: 15785 (98.89%)
Failed: 83 (0.52%)
--> Openib failures: 80 (0.50%)
Skipped: 46 (0.29%)
Timedout: 48 (0.30%)
Here is what I was able to do - note that the resolve messages are
associated with the specific hostname, not the overall map:
Will that work for you? If you like, I can remove the name= field from
the no
Pasha and I *think* we have a fix. However, we're not quite clear on
this part of the code, so we need some more testing and eyes on the
code.
I'll start the tests now -- given that this is a low-frequency bug,
I'm going to run a slightly larger MTT run (several thousand tests)
that'll t
Ralph,
I think the second form would be ideal and would simplify things
greatly.
Greg
On Jan 15, 2009, at 10:53 AM, Ralph Castain wrote:
Here is what I was able to do - note that the resolve messages are
associated with the specific hostname, not the overall map:
Okay, it is in the trunk as of r20284 - I'll file the request to have
it moved to 1.3.1.
Let me know if you get a chance to test the stdout/err stuff in the
trunk - we should try and iterate it so any changes can make 1.3.1 as
well.
Thanks!
Ralph
On Jan 15, 2009, at 11:03 AM, Greg Watso
I don't know what scope of changes require RFCs, but here's a trivial
change.
==
RFC: Eliminate opal_round_up_to_nearest_pow2().
WHAT: Eliminate the function opal_round_up_to_nearest_pow2().
WHY: It's poorly written. A clean rewrite would take
Absolutely! Why wait until the 1.4 while we can have that in the
1.3.1...
george.
On Jan 15, 2009, at 16:39 , Eugene Loh wrote:
I don't know what scope of changes require RFCs, but here's a
trivial change.
==
RFC: Eliminate opal_round_up_
Ditto; kill it.
I marginally prefer 1.4 because it really doesn't affect anything in
the now-more-or-less-static 1.3 series, right?
On Jan 15, 2009, at 5:01 PM, George Bosilca wrote:
Absolutely! Why wait until the 1.4 while we can have that in the
1.3.1...
george.
On Jan 15, 2009, at
Just for reference, if a power of 2 computation is in a performance critical
path, using something like this would be better than a loop:
http://aggregate.org/MAGIC/#Next%20Largest%20Power%20of%202
(it's not the exact same function, just subtract 1 before starting to get
the same function, AFAIK.)
Hi All,
The seventh release candidate of Open MPI v1.3 is now available:
http://www.open-mpi.org/software/ompi/v1.3/
Please run it through it's paces as best you can.
Anticipated release of 1.3 is Friday... of what month or year, I don't know...
This only differs from rc6 with an openib change
Thanks. For my edification: are such trivial changes deserving of
RFCs? Perfect for RFCs? Good for RFCs while I'm still getting my feet
wet, but unnecessary once I get the hang of things?
1.4 was poor counting on my part: 1.3+1=1.4. The new math. I guess
actually 1.3+1=1.3.1. I'm fine
I did a large MTT run (about 7k tests) with the openib patch on rc6
and all came out good. I'll do the same run on rc7 -- the results
should be identical. Will post results tomorrow morning.
On Jan 15, 2009, at 5:24 PM, Tim Mattox wrote:
Hi All,
The seventh release candidate of Open MPI v
On Jan 15, 2009, at 5:36 PM, Eugene Loh wrote:
Thanks. For my edification: are such trivial changes deserving of
RFCs? Perfect for RFCs? Good for RFCs while I'm still getting my
feet wet, but unnecessary once I get the hang of things?
I think that once you're comfortable you can omit RF
14 matches
Mail list logo
