I didn't see exchange between you and Jeff at the end of this email. It
basically nullifies my half-baked concern.
thanks,
--td
Eugene Loh wrote:
Terry Dontje wrote:
Eugene Loh wrote:
I'm on the verge of giving up moving the sendi call in the PML. I
will try one or two last things, incl
On Mar 3, 2009, at 4:04 PM, Eugene Loh wrote:
How about an MCA parameter to switch between this mechanism (early
sendi) and the original behavior (late sendi)?
This is the usual way that we resolve "I want to do X / I want to
do Y" disputes. :-)
I see the smiley face, but am unsure how
Looks okay to me Brian - I went ahead and filed the CMR and sent it on to
Brad for approval.
Ralph
> On Tue, 3 Mar 2009, Brian W. Barrett wrote:
>
>> On Tue, 3 Mar 2009, Jeff Squyres wrote:
>>
>>> 1.3.1rc3 had a race condition in the ORTE shutdown sequence. The only
>>> difference between rc3 a
Jeff Squyres wrote:
On Mar 3, 2009, at 4:04 PM, Eugene Loh wrote:
How about an MCA parameter to switch between this mechanism (early
sendi) and the original behavior (late sendi)?
This is the usual way that we resolve "I want to do X / I want to
do Y" disputes. :-)
I see the smiley fac
I have a problem starting large SMP jobs (e.g., 64 processes on a single
SMP) that might be related to a recent trunk change. (Guessing.) Does
the following ring any bells?
...
...
...
[burl-t5440-0:06798] [[57827,1],42] ORTE_ERROR_LOG: Not found in file
ess_env_module.c at line 299
[burl-t5
I'll take a look - offhand, I don't know of anything limiting you to
<= 64 ppn
On Mar 4, 2009, at 1:49 PM, Eugene Loh wrote:
I have a problem starting large SMP jobs (e.g., 64 processes on a
single SMP) that might be related to a recent trunk change.
(Guessing.) Does the following ring
I just ran a 64ppn job without problem. Couple of possibilities come
to mind:
1. you might have some stale lib around - try blowing things away and
rebuilding
2. there may be a problem in your specific situation. Can you provide
some info on what you are doing (e.g., what environment)?
On Mar 4, 2009, at 14:44 , Eugene Loh wrote:
Let me try another thought here. Why do we have BTL sendi functions
at all? I'll make an assertion and would appreciate feedback: a
BTL sendi function contributes nothing to optimizing send latency.
To optimize send latency in the "immediate
On Wed, 4 Mar 2009, George Bosilca wrote:
I'm churning a lot and not making much progress, but I'll try chewing on
that idea (unless someone points out it's utterly ridiculous). I'll look
into having PML ignore sendi functions altogether and just make the
"send-immediate" path work fast with
George Bosilca wrote:
On Mar 4, 2009, at 14:44 , Eugene Loh wrote:
Let me try another thought here. Why do we have BTL sendi functions
at all? I'll make an assertion and would appreciate feedback: a
BTL sendi function contributes nothing to optimizing send latency.
To optimize send la
Brian W. Barrett wrote:
How about removing the MCA parameter from my earlier proposal and just
having r2 filter out the sendi calls if there are multiple BTLs with
heterogeneous BTLs (ie, some with sendi and some without) to the same
peer. That way, the early sendi will be bypassed in that ca
FYI.
Begin forwarded message:
From: "Matt Mackall"
Date: March 4, 2009 8:27:44 PM EST
To: "mercurial"
Subject: Mercurial 1.2 released!
This is a larger feature release. Visit http://selenic.com/mercurial/
for downloads and more information.
General features:
* explicit closing of nam
12 matches
Mail list logo