[hwloc-devel] Create success (hwloc r1.5.1rc1r4883)

[MPI Team]

Creating nightly hwloc snapshot SVN tarball was a success.

Snapshot:   hwloc 1.5.1rc1r4883
Start time: Wed Oct  3 21:05:02 EDT 2012
End time:   Wed Oct  3 21:08:43 EDT 2012

Your friendly daemon,
Cyrador

[hwloc-devel] Create success (hwloc r1.6a1r4882)

[MPI Team]

Creating nightly hwloc snapshot SVN tarball was a success.

Snapshot:   hwloc 1.6a1r4882
Start time: Wed Oct  3 21:01:02 EDT 2012
End time:   Wed Oct  3 21:05:01 EDT 2012

Your friendly daemon,
Cyrador

Re: [OMPI devel] Open-mpi in red hat 7.3

[Sandra Guija]

I will work on Ralph's suggestion
Thanks all
Sandra Guija

From: sgu...@hotmail.com
To: de...@open-mpi.org
List-Post: devel@lists.open-mpi.org
Date: Wed, 3 Oct 2012 11:47:33 -0700
Subject: Re: [OMPI devel] Open-mpi in red hat 7.3





Hi Jeff, I want to setup a message passing programming environment on Simics, a 
hardware simulation software. Simics have some pre-built target machines, ready 
to use, unfortunately these targets have old OS version (Fedora 5, Red Hat 
7.3).I installed mpich2 on the Red Hat and bump in some many issues, so I want 
to explore my options with open-mpi.I setup an open-mpi cluster on ubuntu 10, 
and it works. But it is quiet of complex to use Ubuntu on simics.
Thanks for replying my email,
Sandra Guija

> From: jsquy...@cisco.com
> Date: Wed, 3 Oct 2012 14:12:03 -0400
> To: de...@open-mpi.org
> Subject: Re: [OMPI devel] Open-mpi in red hat 7.3
> 
> Question: why such an old OS?  Can you upgrade it?  Fedora 7.3 (which is what 
> I assume you mean) and gcc 2.96 are pretty ancient, in computer software 
> terms -- gcc 2.96 is *over 12 years old*.  That's an eternity.
> 
> Additional suggestion: we haven't tested with gcc 2.96 in quite a while, and 
> don't maintain lists of what versions work with (really) old compilers; 
> sorry.  Ralph's suggestion is a good one -- start with the latest Open MPI 
> (1.6.2) and see if that works.  If it doesn't, work backwards in our release 
> series and see which works for you (e.g., if 1.6.2 doesn't work, try the last 
> release in the 1.4.x series -- 1.4.5.  If that doesn't work, try the last 
> release in the 1.2.x series -- 1.2.9.  If that doesn't work, try the last 
> release in the 1.1.x and 1.0.x series).
> 
> 
> 
> On Oct 3, 2012, at 1:30 PM, Ralph Castain wrote:
> 
> > Not sure why any of them wouldn't successfully install - so why not grab 
> > 1.6.2? Is there some problem you aren't telling us?
> > 
> > 
> > On Oct 3, 2012, at 10:20 AM, Sandra Guija  wrote:
> > 
> >> Hello, 
> >> Anyone could provide a feedback about the latest version of open-mpi that 
> >> successfully installs in Red Hat 7.3 gcc 2.96
> >> thanks
> >> Sandra Guija
> >> 
> >> ___ devel mailing list 
> >> de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >> ___
> >> devel mailing list
> >> de...@open-mpi.org
> >> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> > 
> > ___
> > devel mailing list
> > de...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
> 
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
  

___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel  
  

Re: [OMPI devel] Open-mpi in red hat 7.3

[Sandra Guija]

Hi Jeff, I want to setup a message passing programming environment on Simics, a 
hardware simulation software. Simics have some pre-built target machines, ready 
to use, unfortunately these targets have old OS version (Fedora 5, Red Hat 
7.3).I installed mpich2 on the Red Hat and bump in some many issues, so I want 
to explore my options with open-mpi.I setup an open-mpi cluster on ubuntu 10, 
and it works. But it is quiet of complex to use Ubuntu on simics.
Thanks for replying my email,
Sandra Guija

> From: jsquy...@cisco.com
> Date: Wed, 3 Oct 2012 14:12:03 -0400
> To: de...@open-mpi.org
> Subject: Re: [OMPI devel] Open-mpi in red hat 7.3
> 
> Question: why such an old OS?  Can you upgrade it?  Fedora 7.3 (which is what 
> I assume you mean) and gcc 2.96 are pretty ancient, in computer software 
> terms -- gcc 2.96 is *over 12 years old*.  That's an eternity.
> 
> Additional suggestion: we haven't tested with gcc 2.96 in quite a while, and 
> don't maintain lists of what versions work with (really) old compilers; 
> sorry.  Ralph's suggestion is a good one -- start with the latest Open MPI 
> (1.6.2) and see if that works.  If it doesn't, work backwards in our release 
> series and see which works for you (e.g., if 1.6.2 doesn't work, try the last 
> release in the 1.4.x series -- 1.4.5.  If that doesn't work, try the last 
> release in the 1.2.x series -- 1.2.9.  If that doesn't work, try the last 
> release in the 1.1.x and 1.0.x series).
> 
> 
> 
> On Oct 3, 2012, at 1:30 PM, Ralph Castain wrote:
> 
> > Not sure why any of them wouldn't successfully install - so why not grab 
> > 1.6.2? Is there some problem you aren't telling us?
> > 
> > 
> > On Oct 3, 2012, at 10:20 AM, Sandra Guija  wrote:
> > 
> >> Hello, 
> >> Anyone could provide a feedback about the latest version of open-mpi that 
> >> successfully installs in Red Hat 7.3 gcc 2.96
> >> thanks
> >> Sandra Guija
> >> 
> >> ___ devel mailing list 
> >> de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
> >> ___
> >> devel mailing list
> >> de...@open-mpi.org
> >> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> > 
> > ___
> > devel mailing list
> > de...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
> 
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
  

Re: [OMPI devel] Open-mpi in red hat 7.3

[Jeff Squyres]

Question: why such an old OS?  Can you upgrade it?  Fedora 7.3 (which is what I 
assume you mean) and gcc 2.96 are pretty ancient, in computer software terms -- 
gcc 2.96 is *over 12 years old*.  That's an eternity.

Additional suggestion: we haven't tested with gcc 2.96 in quite a while, and 
don't maintain lists of what versions work with (really) old compilers; sorry.  
Ralph's suggestion is a good one -- start with the latest Open MPI (1.6.2) and 
see if that works.  If it doesn't, work backwards in our release series and see 
which works for you (e.g., if 1.6.2 doesn't work, try the last release in the 
1.4.x series -- 1.4.5.  If that doesn't work, try the last release in the 1.2.x 
series -- 1.2.9.  If that doesn't work, try the last release in the 1.1.x and 
1.0.x series).



On Oct 3, 2012, at 1:30 PM, Ralph Castain wrote:

> Not sure why any of them wouldn't successfully install - so why not grab 
> 1.6.2? Is there some problem you aren't telling us?
> 
> 
> On Oct 3, 2012, at 10:20 AM, Sandra Guija  wrote:
> 
>> Hello, 
>> Anyone could provide a feedback about the latest version of open-mpi that 
>> successfully installs in Red Hat 7.3 gcc 2.96
>> thanks
>> Sandra Guija
>> 
>> ___ devel mailing list 
>> de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] Open-mpi in red hat 7.3

[Ralph Castain]

Not sure why any of them wouldn't successfully install - so why not grab 1.6.2? 
Is there some problem you aren't telling us?


On Oct 3, 2012, at 10:20 AM, Sandra Guija  wrote:

> Hello, 
> Anyone could provide a feedback about the latest version of open-mpi that 
> successfully installs in Red Hat 7.3 gcc 2.96
> thanks
> Sandra Guija
> 
> ___ devel mailing list 
> de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] Open-mpi in red hat 7.3

[Sandra Guija]

Hello, Anyone could provide a feedback about the latest version of open-mpi 
that successfully installs in Red Hat 7.3 gcc 2.96
thanks
Sandra Guija
  

___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel  
  

[OMPI devel] Open-mpi in red hat 7.3

[Sandra Guija]

Hello, I would like to know what is the latest version I can succesfully 
install in Red Hat 7.3 gcc 2.96
thanks
Sandra Guija
  

Re: [OMPI devel] RFC: hwloc object userdata

[Ralph Castain]

If you're going that route, we're probably better off using your original 
"hash" based solution so people can just assign a character string to "point" 
to their block of data. Otherwise, we get into the problem of potentially 
overlapping indexes with people on branches.


On Oct 3, 2012, at 7:29 AM, Jeff Squyres  wrote:

> On Oct 3, 2012, at 10:22 AM, George Bosilca wrote:
> 
>> In the case such a functionality become necessary, I would suggest we use a 
>> mechanism similar to the attributes in MPI (but without the multi-language 
>> mess). That will allow whoever want to attach data to a hwloc node, to do it 
>> without the mess of dealing with reserving a slot. It might require a little 
>> bit more memory, but so far the number of nodes in the HWLOC data is limited.
> 
> You mean something like putting this in opal/mca/hwloc/base/base.h:
> 
> typedef enum {
>  OPAL_HWLOC_BASE_RMAPS_BASE,
>  OPAL_HWLOC_BASE_BTL_OPENIB,
>  OPAL_HWLOC_BASE_GEORGE_STUFF,
>  OPAL_HWLOC_BASE_JEFF_STUFF,
>  /* ... */
>  OPAL_HWLOC_BASE_MAX
> } opal_hwloc_base_userdata_consumers_t;
> 
> And then:
> 
> 0. if any new upper-level consumer wants to hang stuff off hwloc userdata, 
> they just add another enum
> 1. hwloc base hangs a (void *opal[OPAL_HWLOC_BASE_MAX]) off each hwloc obj
> 2. each upper level consumer uses their enum to set/get their stuff
> 
> Is that what you're thinking?
> 
> 
>> george.
>> 
>> On Oct 3, 2012, at 16:13 , Jeff Squyres  wrote:
>> 
>>> WHAT: allowing multiple entities in the OMPI code base to hang data off 
>>> hwloc_obj->userdata
>>> 
>>> WHY: anticipating that more parts of the OMPI code base will be using the 
>>> hwloc data
>>> 
>>> WHERE: hwloc base
>>> 
>>> WHEN: no real hurry; Ralph and I just identified the potential for this 
>>> issue this morning.  We're not aware of it being an actual problem (yet).
>>> 
>>> MORE DETAIL:
>>> 
>>> The rmaps base (in mpirun) is currently hanging its own data off various 
>>> objects in the hwloc topology tree.  However, it should be noted that the 
>>> hwloc topology tree is a global data structure in each MPI processes; 
>>> multiple upper-level entities in the ORTE and OMPI layers may want to hang 
>>> their own userdata off hwloc objects.
>>> 
>>> Ralph and I figured that some functionality could be added to the hwloc 
>>> base to hang a opal_pointer_array off each hwloc object; each array value 
>>> will be a (void*).  Then upper-level entities can reserve a slot in all the 
>>> pointer arrays and store whatever they want in their (void*) slot.
>>> 
>>> For example, if the openib BTL wants to use the hwloc data and hang its own 
>>> userdata off hwloc objects, it can call the hwloc base and reserve a slot.  
>>> The hwloc base will say "Ok, you can have slot 7".  Then the openib BTL can 
>>> always use slot 7 in the opal_pointer_array off any hwloc object.
>>> 
>>> Does this sound reasonable?
>>> 
>>> -- 
>>> Jeff Squyres
>>> jsquy...@cisco.com
>>> For corporate legal information go to: 
>>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>> 
>>> 
>>> ___
>>> devel mailing list
>>> de...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> 
>> 
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> 
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] RFC: hwloc object userdata

[Jeff Squyres]

On Oct 3, 2012, at 10:22 AM, George Bosilca wrote:

> In the case such a functionality become necessary, I would suggest we use a 
> mechanism similar to the attributes in MPI (but without the multi-language 
> mess). That will allow whoever want to attach data to a hwloc node, to do it 
> without the mess of dealing with reserving a slot. It might require a little 
> bit more memory, but so far the number of nodes in the HWLOC data is limited.

You mean something like putting this in opal/mca/hwloc/base/base.h:

typedef enum {
  OPAL_HWLOC_BASE_RMAPS_BASE,
  OPAL_HWLOC_BASE_BTL_OPENIB,
  OPAL_HWLOC_BASE_GEORGE_STUFF,
  OPAL_HWLOC_BASE_JEFF_STUFF,
  /* ... */
  OPAL_HWLOC_BASE_MAX
} opal_hwloc_base_userdata_consumers_t;

And then:

0. if any new upper-level consumer wants to hang stuff off hwloc userdata, they 
just add another enum
1. hwloc base hangs a (void *opal[OPAL_HWLOC_BASE_MAX]) off each hwloc obj
2. each upper level consumer uses their enum to set/get their stuff

Is that what you're thinking?


>  george.
> 
> On Oct 3, 2012, at 16:13 , Jeff Squyres  wrote:
> 
>> WHAT: allowing multiple entities in the OMPI code base to hang data off 
>> hwloc_obj->userdata
>> 
>> WHY: anticipating that more parts of the OMPI code base will be using the 
>> hwloc data
>> 
>> WHERE: hwloc base
>> 
>> WHEN: no real hurry; Ralph and I just identified the potential for this 
>> issue this morning.  We're not aware of it being an actual problem (yet).
>> 
>> MORE DETAIL:
>> 
>> The rmaps base (in mpirun) is currently hanging its own data off various 
>> objects in the hwloc topology tree.  However, it should be noted that the 
>> hwloc topology tree is a global data structure in each MPI processes; 
>> multiple upper-level entities in the ORTE and OMPI layers may want to hang 
>> their own userdata off hwloc objects.
>> 
>> Ralph and I figured that some functionality could be added to the hwloc base 
>> to hang a opal_pointer_array off each hwloc object; each array value will be 
>> a (void*).  Then upper-level entities can reserve a slot in all the pointer 
>> arrays and store whatever they want in their (void*) slot.
>> 
>> For example, if the openib BTL wants to use the hwloc data and hang its own 
>> userdata off hwloc objects, it can call the hwloc base and reserve a slot.  
>> The hwloc base will say "Ok, you can have slot 7".  Then the openib BTL can 
>> always use slot 7 in the opal_pointer_array off any hwloc object.
>> 
>> Does this sound reasonable?
>> 
>> -- 
>> Jeff Squyres
>> jsquy...@cisco.com
>> For corporate legal information go to: 
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>> 
>> 
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI devel] RFC: hwloc object userdata

[George Bosilca]

In the case such a functionality become necessary, I would suggest we use a 
mechanism similar to the attributes in MPI (but without the multi-language 
mess). That will allow whoever want to attach data to a hwloc node, to do it 
without the mess of dealing with reserving a slot. It might require a little 
bit more memory, but so far the number of nodes in the HWLOC data is limited.

  george.

On Oct 3, 2012, at 16:13 , Jeff Squyres  wrote:

> WHAT: allowing multiple entities in the OMPI code base to hang data off 
> hwloc_obj->userdata
> 
> WHY: anticipating that more parts of the OMPI code base will be using the 
> hwloc data
> 
> WHERE: hwloc base
> 
> WHEN: no real hurry; Ralph and I just identified the potential for this issue 
> this morning.  We're not aware of it being an actual problem (yet).
> 
> MORE DETAIL:
> 
> The rmaps base (in mpirun) is currently hanging its own data off various 
> objects in the hwloc topology tree.  However, it should be noted that the 
> hwloc topology tree is a global data structure in each MPI processes; 
> multiple upper-level entities in the ORTE and OMPI layers may want to hang 
> their own userdata off hwloc objects.
> 
> Ralph and I figured that some functionality could be added to the hwloc base 
> to hang a opal_pointer_array off each hwloc object; each array value will be 
> a (void*).  Then upper-level entities can reserve a slot in all the pointer 
> arrays and store whatever they want in their (void*) slot.
> 
> For example, if the openib BTL wants to use the hwloc data and hang its own 
> userdata off hwloc objects, it can call the hwloc base and reserve a slot.  
> The hwloc base will say "Ok, you can have slot 7".  Then the openib BTL can 
> always use slot 7 in the opal_pointer_array off any hwloc object.
> 
> Does this sound reasonable?
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

[OMPI devel] RFC: hwloc object userdata

[Jeff Squyres]

WHAT: allowing multiple entities in the OMPI code base to hang data off 
hwloc_obj->userdata

WHY: anticipating that more parts of the OMPI code base will be using the hwloc 
data

WHERE: hwloc base

WHEN: no real hurry; Ralph and I just identified the potential for this issue 
this morning.  We're not aware of it being an actual problem (yet).

MORE DETAIL:

The rmaps base (in mpirun) is currently hanging its own data off various 
objects in the hwloc topology tree.  However, it should be noted that the hwloc 
topology tree is a global data structure in each MPI processes; multiple 
upper-level entities in the ORTE and OMPI layers may want to hang their own 
userdata off hwloc objects.

Ralph and I figured that some functionality could be added to the hwloc base to 
hang a opal_pointer_array off each hwloc object; each array value will be a 
(void*).  Then upper-level entities can reserve a slot in all the pointer 
arrays and store whatever they want in their (void*) slot.

For example, if the openib BTL wants to use the hwloc data and hang its own 
userdata off hwloc objects, it can call the hwloc base and reserve a slot.  The 
hwloc base will say "Ok, you can have slot 7".  Then the openib BTL can always 
use slot 7 in the opal_pointer_array off any hwloc object.

Does this sound reasonable?

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/