Never mind; this commit didn't work at all. I'm going to back it
out. :-(
On Mar 4, 2008, at 7:25 PM, Jeff Squyres wrote:
My apologies; apparently the SVN merge of PLPA somehow didn't work
properly. The next time you "svn up", you'll get a conflict warning
about opal/mca/paffinity/linux/pl
Ok. Current plan is to wait for Ralph to finish his big ORTE merge,
probably give it a day or two to get a solid night's worth of MTT
testing in, and then merge in the new PLPA.
Thanks for all your patience, guys...
On Feb 26, 2008, at 3:43 AM, Sharon Melamed wrote:
Jeff,
I prefer opti
Jeff,
I prefer option 1. You should use your branch and merge it to the
trunk. We shuold synchronize with the trunk and finish our work. The
reason that we made the PLPA change in our brunch is that we needed it
to our work. But we made it as a temporary change until the real thing
will be in the
Sure.
-Original Message-
From: devel-boun...@open-mpi.org [mailto:devel-boun...@open-mpi.org] On
Behalf Of Jeff Squyres
Sent: Thursday, February 21, 2008 6:58 PM
To: Open MPI Developers
Subject: Re: [OMPI devel] PLPA ready?
Sounds perfect.
How about this -- since your and my changes
hy not change those API's including their
signature in paffinity.h
Sharon.
-Original Message-
From: devel-boun...@open-mpi.org [mailto:devel-boun...@open-mpi.org]
On
Behalf Of Jeff Squyres
Sent: Thursday, February 21, 2008 5:19 PM
To: Open MPI Developers
Subject: Re: [OMPI devel] PLPA
n't see why not change those API's including their
signature in paffinity.h
Sharon.
-Original Message-
From: devel-boun...@open-mpi.org [mailto:devel-boun...@open-mpi.org] On
Behalf Of Jeff Squyres
Sent: Thursday, February 21, 2008 5:19 PM
To: Open MPI Developers
Subject: Re: [OM
On Feb 21, 2008, at 7:13 AM, Jeff Squyres wrote:
Right, but the plpa_solaris_module.c file will need to be updated
with
the new function signatures so that it will still compile (i.e., if
you're going to be changing the function signatures in paffinity.h).
Hah -- I meant paffinity_solaris_m
On Feb 21, 2008, at 7:01 AM, Sharon Melamed wrote:
1. Yes, I need both parameters when querying socket and cores.
2. I don't think that sun will concern if we will change the
get_processor/socket/core_info because as Pak Lui from Sun said in
one of
his early emails "I am guessing it will not m
functions that Solaris doesn't really implement yet, right?"
Sharon.
-Original Message-
From: devel-boun...@open-mpi.org [mailto:devel-boun...@open-mpi.org] On
Behalf Of Jeff Squyres
Sent: Thursday, February 21, 2008 4:18 PM
To: Open MPI Developers
Subject: Re: [OMPI devel] PL
On Feb 20, 2008, at 7:53 AM, Sharon Melamed wrote:
I guess I was torn between reporting num_processors/sockets and
max_socket|core_id. Really, you need both, right? It is possible
that the number of processors and/or sockets are not contiguous.
I need both *because* the number of processor is
On Feb 20, 2008 3:01 PM, Jeff Squyres wrote:
> On Feb 19, 2008, at 10:12 AM, Sharon Melamed wrote:
>
> I guess I was torn between reporting num_processors/sockets and
> max_socket|core_id. Really, you need both, right? It is possible
> that the number of processors and/or sockets are not contigu
On Feb 19, 2008, at 10:12 AM, Sharon Melamed wrote:
In the patch you sent the variables: num_processors, num_sockets and
num_cores are lost outside the paffinity framework.
I need those in the ODLS framework. what do think about the attached
patch?
I guess I was torn between reporting num_pr
Jeff,
In the patch you sent the variables: num_processors, num_sockets and
num_cores are lost outside the paffinity framework.
I need those in the ODLS framework. what do think about the attached patch?
Sharon.
2008/2/19 Jeff Squyres :
> $%@#$% Sorry.
>
> I saw that and fixed it in my local OMP
I am guessing it will not messing us up because these are the functions
that Solaris doesn't really implement yet, right? Last time I check we
are still hunting for some stable interfaces in Solaris to implement them.
Terry Dontje wrote:
Jeff Squyres wrote:
$%@#$% Sorry.
I saw that and fixe
Will do. I stress that it *might* be worthwhile -- I think it at
least partially depends on what Voltaire does and whether they think
it should change (since they're the first ones using the paffinity API
in a meaningful way).
If we want to change it, it would probably be good to do so bef
Jeff Squyres wrote:
$%@#$% Sorry.
I saw that and fixed it in my local OMPI SVN copy last night as well.
Here's a patch to make it go (I obviously didn't want to commit this
until the new PLPA goes in). We *may* want to revise the paffinity
API to match PLPA, not because Linux is the one-and
$%@#$% Sorry.
I saw that and fixed it in my local OMPI SVN copy last night as well.
Here's a patch to make it go (I obviously didn't want to commit this
until the new PLPA goes in). We *may* want to revise the paffinity
API to match PLPA, not because Linux is the one-and-only-way, but
b
Jeff,
The new PLPA fails in compilation. there is a need to change the
paffinity API's:
1. max_processor_id with one parameter --> get_processor_info with 2 parameters.
2. max_socket with one parameter --> get_socket_info with 2 parameters.
3. max_core with 2 parameters --> get_core_info with 3 pa
18 matches
Mail list logo
