First, sorry about the previous message - I'm incapable of using my e-
mail apparently.
Based on discusions with people when this came up for LAM, it sounds
like this will become common for the next set of major releases from
the distros. The feature is fairly new to GNU ld, but has some ni
Brian
--
Brian Barrett
There is an art . . . to flying. The knack lies in learning how to
throw yourself at the ground and miss.
On Jul 23, 2008, at 9:32, Jeff Squyres wrote:
Release managers: I have created ticket 1409 for this issue. I need
a ruling: do you want this fixed for v1.3?
Release managers: I have created ticket 1409 for this issue. I need a
ruling: do you want this fixed for v1.3?
https://svn.open-mpi.org/trac/ompi/ticket/1409
PRO: It's not too heinous to fix, but it does require moving some code
around.
CON: This is the first time anyone has ever run i
Unfortunately over the last couple of days I realize that the patches
from the trunk are moved to the 1.3 too rapidly and usually without
much testing. I would like to remember to everybody that the 1.3,
while opened for community commits, is supposed to become stable at
one point and that
Yes, it may well be...
It needs to handle the case where paffinity can return "Sorry, I don't
have this information for you."
On Jul 23, 2008, at 11:40 AM, Lenny Verkhovsky wrote:
can this also be a reason for seqv on NUMA nodes(#1382) , that I
cant recreate ?
On 7/23/08, Jeff Squyres
On Jul 23, 2008, at 11:48 AM, Terry Dontje wrote:
Ok, so I thought I saw slow down with Solaris. Not sure it is the
same thing (wouldn't think so) but I'll test this out soon.
Ok. Check the state of the solaris paffinity component (I don't know
what state it's in these days) and ensure t
Fixed in r19001. Please re-test; it fixes the problem for me (i.e.,
no need to manually specify sched_yield=0).
BTW, this never came up before because:
- the ODLS used to use paffinity, but before PLPA supported the
topology stuff and therefore always returned the number of processors
- wh
Jeff Squyres wrote:
On Jul 23, 2008, at 10:37 AM, Terry Dontje wrote:
This seems to work for me too. What is interesting is my experiments
have shown that if you run on RH5.1 you don't need to set
mpi_yield_when_idle to 0.
Yes, this makes sense -- on RHEL5.1, it's a much newer Linux kernel
can this also be a reason for seqv on NUMA nodes(#1382) , that I cant
recreate ?
On 7/23/08, Jeff Squyres wrote:
>
> On Jul 23, 2008, at 10:37 AM, Terry Dontje wrote:
>
> This seems to work for me too. What is interesting is my experiments have
>> shown that if you run on RH5.1 you don't need t
On Jul 23, 2008, at 10:37 AM, Terry Dontje wrote:
This seems to work for me too. What is interesting is my
experiments have shown that if you run on RH5.1 you don't need to
set mpi_yield_when_idle to 0.
Yes, this makes sense -- on RHEL5.1, it's a much newer Linux kernel
and PLPA works as
I added a tad more output to the debugging statement so you can see
how many processors were found, how many children we have, and what
the sched_yield will be set to...
Besides, that way I got to be the one that hit r19000!
On Jul 23, 2008, at 9:21 AM, Jeff Squyres wrote:
It's PLPA that's
It's PLPA that's at fault here; I'm running on an older Linux kernel
that doesn't have the topology information available. So PLPA is
saying "can't give you anything, sorry" (to include how many
processors are available) -- but that might not be true.
I need to think about this a bit to co
Here is a real simple test that will tell us a bunch about what is
going on: run this again with -mca odls_base_verbose 5. You'll get
some output, but what we are looking for specifically is a message
that includes "launch oversubscribed set to...". This will tell us
what ORTE -thinks- the
This seems to work for me too. What is interesting is my experiments
have shown that if you run on RH5.1 you don't need to set
mpi_yield_when_idle to 0.
--td
Jeff Squyres wrote:
Doh! I guess we still don't have that calculating right yet; I
thought we had fixed that...
[7:12] svbu-mpi052:
On Jul 23, 2008, at 10:08 AM, Ralf Wildenhues wrote:
Is the attached patch what you're talking about?
If so, I'll commit to trunk, v1.2, and v1.3.
Can you verify that it work with a pristine build? The dependencies
as
such look sane to me, also the cruft removal, but I fail to see how
you
Doh! I guess we still don't have that calculating right yet; I
thought we had fixed that...
[7:12] svbu-mpi052:~/svn/ompi-tests/NetPIPE-3.7.1 % mpirun --mca
mpi_paffinity_alone 1 -np 2 --mca btl sm,self --mca
mpi_yield_when_idle 0 NPmpi
0: svbu-mpi052
1: svbu-mpi052
Now starting the main
Hi Jeff,
* Jeff Squyres wrote on Wed, Jul 23, 2008 at 03:54:50PM CEST:
>
> Is the attached patch what you're talking about?
>
> If so, I'll commit to trunk, v1.2, and v1.3.
Can you verify that it work with a pristine build? The dependencies as
such look sane to me, also the cruft removal, but I
Can you try the HEAD with the mpi_yield_when_idle set to 0 please.
Thanks,
george.
On Jul 23, 2008, at 3:39 PM, Jeff Squyres wrote:
Short version: I'm seeing a large performance drop between r18850
and the SVN HEAD.
Longer version:
FWIW, I ran the tests on 3 versions on a woodcrest-
Brian / Ralf --
Is the attached patch what you're talking about?
If so, I'll commit to trunk, v1.2, and v1.3.
On Jul 21, 2008, at 7:08 PM, Brian W. Barrett wrote:
On Sun, 20 Jul 2008 21:13:48 +0200, Ralf Wildenhues
wrote:
* Funda Wang wrote on Sun, Jul 20, 2008 at 05:29:57AM CEST:
I'm cur
Short version: I'm seeing a large performance drop between r18850 and
the SVN HEAD.
Longer version:
FWIW, I ran the tests on 3 versions on a woodcrest-class x86_64
machine running RHEL4U4:
* Trunk HEAD (r18997)
* r18973 --> had to patch the cpu64* thingy in openib btl to get it to
compil
This has now been fixed as of https://svn.open-mpi.org/trac/ompi/changeset/18995
; MTT should [finally] run tonight without problems.
On Jul 22, 2008, at 12:38 PM, Jeff Squyres wrote:
On Jul 22, 2008, at 12:32 PM, Roland Dreier wrote:
So I think using byteorder.h is not a good idea (note th
Sorry Terry, :).
-- Forwarded message --
From: Lenny Verkhovsky
List-Post: devel@lists.open-mpi.org
Date: Jul 23, 2008 2:22 PM
Subject: Re: [OMPI devel] [OMPI bugs] [Open MPI] #1250: Performance problem
on SM
To: Lenny Berkhovsky
On 7/23/08, Terry Dontje wrote:
>
> I didn't s
I rechecked in on the same node, still no degradation,
see results attached.
On 7/22/08, Open MPI wrote:
>
> #1250: Performance problem on SM
>
> +---
> Reporter: bosilca |Owner: bosilca
> Type: defect |
23 matches
Mail list logo
