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
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
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
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
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.)
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
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
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
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
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:
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
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
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%)
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:
14 matches
Mail list logo
