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,
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
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
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
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
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
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
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
