Creating nightly hwloc snapshot SVN tarball was a success.
Snapshot: hwloc 1.1.1a1r3093
Start time: Tue Jan 18 21:03:34 EST 2011
End time: Tue Jan 18 21:06:01 EST 2011
Your friendly daemon,
Cyrador
Thanks for fixing it up!
On Jan 18, 2011, at 6:13 PM, Samuel Thibault wrote:
> Jeff Squyres, le Tue 18 Jan 2011 20:00:42 +0100, a écrit :
>> On Jan 12, 2011, at 10:10 AM, Samuel Thibault wrote:
>>> This is not what I meant: hwloc_alloc_membind_policy's purpose is only
>>> to allocate bound
Jeff Squyres, le Tue 18 Jan 2011 20:00:42 +0100, a écrit :
> On Jan 12, 2011, at 10:10 AM, Samuel Thibault wrote:
> > This is not what I meant: hwloc_alloc_membind_policy's purpose is only
> > to allocate bound memory. It happens that hwloc_alloc_membind_policy
> > _may_ change the process policy
I took the liberty of committing this in r3090.
On Jan 18, 2011, at 2:00 PM, Jeff Squyres wrote:
> On Jan 12, 2011, at 10:10 AM, Samuel Thibault wrote:
>
>> This is not what I meant: hwloc_alloc_membind_policy's purpose is only
>> to allocate bound memory. It happens that
Le 18/01/2011 19:38, Bernd Kallies a écrit :
> max_os_index = 512, HWLOC_BITS_PER_LONG = 64, rounding gives
> max_os_index = 576.
>
> I also saw the same behaviour on a much smaller machine (usual 2-socket
> Nehalem-EP). CONFIG_NODES_SHIFT is not found in /proc/config.gz.
> max_os_index = 64,
On Jan 12, 2011, at 10:10 AM, Samuel Thibault wrote:
> This is not what I meant: hwloc_alloc_membind_policy's purpose is only
> to allocate bound memory. It happens that hwloc_alloc_membind_policy
> _may_ change the process policy in order to be able to bind memory
> at all (when the underlying
On Tue, 2011-01-18 at 19:11 +0100, Brice Goglin wrote:
> Le 18/01/2011 17:40, Bernd Kallies a écrit :
> > Hallo,
> >
> > I'm using hwloc-1.1 on Linux 2.6.32.19 (x86_64) on a machine that has
> > several NUMA nodes. It seems to me that there are unwanted bits left in
> > the nodeset "set", when
Le 18/01/2011 17:40, Bernd Kallies a écrit :
> Hallo,
>
> I'm using hwloc-1.1 on Linux 2.6.32.19 (x86_64) on a machine that has
> several NUMA nodes. It seems to me that there are unwanted bits left in
> the nodeset "set", when calling hwloc_get_membind_nodeset(topo,
> set, ...) after a successful
Hallo,
I'm using hwloc-1.1 on Linux 2.6.32.19 (x86_64) on a machine that has
several NUMA nodes. It seems to me that there are unwanted bits left in
the nodeset "set", when calling hwloc_get_membind_nodeset(topo,
set, ...) after a successful hwloc_set_membind() or
hwloc_set_membind_nodeset().
As previously discussed, Ralph is stepping back from being the v1.4 GK because
of other time commitments.
I was reminded that I was the backup 1.4 GK, so I'll be stepping in.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
Pascal's HG tree looks good to me.
https://bitbucket.org/devezep/new-romio-for-openmpi
I think it should be committed back to the SVN trunk for more wide-spread
testing (e.g., on non-NFS filesystems -- I don't have any parallel
filesystems).
--
Jeff Squyres
jsquy...@cisco.com
For
On Jan 18, 2011, at 9:31 AM, Jeff Squyres wrote:
> It looks like you manually updated the hg repo to be v1.5, so I guess we can
> go from there (i.e., I'll review and send feedback). But in the future, you
> might want to try the above procedures, instead.
Wrong -- you updated it to the SVN
IMHO, it's (much) easier to get an SVN checkout of the tree you're trying to
sync with and then follow the procedures on that wiki page for SVN + Mercurial
interaction. This allows two things:
1. You can easily stay up-to-date with SVN changes, even on release branches.
2. You can
Hmm. That looks like a merge gone bad; I'm not sure what happened there. It
could well be an artifact of traversing from 1.5 to 1.4, or something like
that.
I would not re-remove these files.
On Jan 17, 2011, at 11:11 AM, Pascal Deveze wrote:
> Jeff,
>
> You removed the following files
On 01/18/2011 07:48 AM, Jeff Squyres wrote:
> IBCM is broken and disabled (has been for a long time).
>
> Did you mean RDMACM?
>
>
No I think I meant OMPI oob.
sorry,
--
Oracle
Terry D. Dontje | Principal Software Engineer
Developer Tools Engineering | +1.781.442.2631
Oracle *- Performance
+1. I'm afraid I don't know why offhand there would be such differences. I'm
thinking that you'll need to dive a little deeper to figure it out; sorry. :-(
On Jan 16, 2011, at 10:54 AM, Shamis, Pavel wrote:
> Well, then I would suspect rdmacm vs oob QP configuration. They supposed to
> be
IBCM is broken and disabled (has been for a long time).
Did you mean RDMACM?
On Jan 18, 2011, at 6:22 AM, Terry Dontje wrote:
> Could the issue have anything to do with the how OMPI implements lazy
> connections with IBCM? Does setting the mca parameter mpi_preconnect_all to
> 1 change
Are the abstractions anything like Bernd's perl bindings, perchance?
http://search.cpan.org/~bka/
On Jan 17, 2011, at 3:02 PM, Guy Streeter wrote:
> I am currently working to get a public git repository set up so that I can
> share the work. In the meantime, my first pass at python
Could the issue have anything to do with the how OMPI implements lazy
connections with IBCM? Does setting the mca parameter
mpi_preconnect_all to 1 change things?
--td
On 01/16/2011 04:12 AM, Doron Shoham wrote:
Hi,
The gather hangs only in liner_sync algorithm but works with
basic_linear
19 matches
Mail list logo
