Re: [OMPI devel] Conversion to GitHub: POSTPONED

2014-09-23 Thread Jeff Squyres (jsquyres) 
On Sep 23, 2014, at 7:52 PM, Jed Brown  wrote:

> I don't have experience with GerritHub, but Bitbucket supports this
> feature (permissions on branch names/globs) and we use it in PETSc.

Thanks for the info.  Paul Hargrove said pretty much the same thing to me, 
off-list.

I'll check it out.

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

[hwloc-devel] Create success (hwloc git 1.9.1-11-g6ec83e5)

2014-09-23 Thread MPI Team 
Creating nightly hwloc snapshot git tarball was a success.

Snapshot:   hwloc 1.9.1-11-g6ec83e5
Start time: Tue Sep 23 21:02:56 EDT 2014
End time:   Tue Sep 23 21:04:19 EDT 2014

Your friendly daemon,
Cyrador

[hwloc-devel] Create success (hwloc git dev-235-g415b593)

2014-09-23 Thread MPI Team 
Creating nightly hwloc snapshot git tarball was a success.

Snapshot:   hwloc dev-235-g415b593
Start time: Tue Sep 23 21:01:02 EDT 2014
End time:   Tue Sep 23 21:02:46 EDT 2014

Your friendly daemon,
Cyrador

Re: [OMPI devel] Conversion to GitHub: POSTPONED

2014-09-23 Thread Jed Brown 
"Jeff Squyres (jsquyres)"  writes:
> GerritHub claims to allow us to effectively have ACLs on branches.
> I.e., everyone could commit on master, but only release managers can
> commit on release branches.  This would be nice, and would allow us to
> avoid having the 2 repos, like we're currently planning to do at
> Github (i.e., "ompi" and "ompi-release").

I don't have experience with GerritHub, but Bitbucket supports this
feature (permissions on branch names/globs) and we use it in PETSc.


pgpGdCnibB071.pgp
Description: PGP signature

Re: [hwloc-devel] Using hwloc to detect Hard Disks

2014-09-23 Thread Ralph Castain 
True - but we intend to collect the inventory as root anyway. :-)

On Sep 23, 2014, at 1:50 PM, Christopher Samuel  wrote:

> On 24/09/14 00:57, Ralph Castain wrote:
> 
>> Memory info is available from lshw, though they are a GPL code:
> 
> FWIW on this laptop (Intel Haswell) lshw only report DIMM info when run
> as root, which I suspect would point them to accessing DMI information
> via /dev/mem.
> 
> Using strace supports this:
> 
> 3405  open("/dev/mem", O_RDONLY)= -1 EACCES (Permission denied)
> 
> FWIW dmidecode does the same.
> 
> samuel@haswell:~$ dmidecode
> # dmidecode 2.12
> /dev/mem: Permission denied
> 
> All the best,
> Chris
> -- 
> Christopher SamuelSenior Systems Administrator
> VLSCI - Victorian Life Sciences Computation Initiative
> Email: sam...@unimelb.edu.au Phone: +61 (0)3 903 55545
> http://www.vlsci.org.au/  http://twitter.com/vlsci
> 
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/hwloc-devel/2014/09/4238.php

Re: [hwloc-devel] Using hwloc to detect Hard Disks

2014-09-23 Thread Christopher Samuel 
On 24/09/14 00:57, Ralph Castain wrote:

> Memory info is available from lshw, though they are a GPL code:

FWIW on this laptop (Intel Haswell) lshw only report DIMM info when run
as root, which I suspect would point them to accessing DMI information
via /dev/mem.

Using strace supports this:

3405  open("/dev/mem", O_RDONLY)= -1 EACCES (Permission denied)

FWIW dmidecode does the same.

samuel@haswell:~$ dmidecode
# dmidecode 2.12
/dev/mem: Permission denied

All the best,
Chris
-- 
 Christopher SamuelSenior Systems Administrator
 VLSCI - Victorian Life Sciences Computation Initiative
 Email: sam...@unimelb.edu.au Phone: +61 (0)3 903 55545
 http://www.vlsci.org.au/  http://twitter.com/vlsci

Re: [OMPI devel] Conversion to GitHub: POSTPONED

2014-09-23 Thread Jeff Squyres (jsquyres) 
At just about at the last minute, a new contender showed up: GerritHub.io.

GerritHub claims to allow us to effectively have ACLs on branches.  I.e., 
everyone could commit on master, but only release managers can commit on 
release branches.  This would be nice, and would allow us to avoid having the 2 
repos, like we're currently planning to do at Github (i.e., "ompi" and 
"ompi-release").

We need a little time to investigate this, and it seems prudent to postpone the 
transition tomorrow.

We'll tentatively aim for *next* Wednesday, October 1, 2014.




On Sep 23, 2014, at 11:53 AM, Jeff Squyres (jsquyres)  
wrote:

> REMINDER: The conversion of Open MPI's Subversion repository and Trac tickets 
> will be happening tomorrow, Wednesday, September 24, 2014.
> 
> SVN and Trac will be going read-only at 8am US Eastern tomorrow, and the 
> conversion process will begin.  I anticipate it taking all day.
> 
> I'll send an "all clear" email when I'm all finished, along with additional 
> details.
> 
> You should probably go read up on how we're going to use GitHub:
> 
>https://github.com/open-mpi/ompi/wiki
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 


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

Re: [hwloc-devel] Using hwloc to detect Hard Disks

2014-09-23 Thread Brice Goglin 
Le 23/09/2014 21:06, Pedaballe, Vineet a écrit :
> 4a. Network Adapters (Ethernet)
>   a. Model
>   b. Speed

Both supported and currently negociated link speed?

On Linux, we'll have to use the ethtool interface.

>   c. Serial Number (if applicable)
>   d. MAC address
> 4b. Network Adapters (Infiniband)
>   a. Model
>   b. Speed
>   c. Serial Number (if applicable)
>   d. MAC address

We'll to use the verbs or libfabric or whatever interface.

> 4. Host Bus Adapters
>   a. Manufacturer
>   b. Serial Number
>   c. MAC address

What kind of adapter are you talking about here? Hostbridge?

> 6. Coprocessors
>   a. Manufacturer
>   b. Serial Number

We'll need an explicit list of supported coprocessors/accelerators and
specific ways to retrieve the S/N for each of them.

> 7. Other PCI Devices
>   a. Device ID
>   b. Device Serial number (if applicable)

IIRC the serial number isn't standardized anywhere in the PCI config
space, this item is likely impossible.

Brice

Re: [OMPI devel] Need to know your Github ID

2014-09-23 Thread Vishwanath Venkatesan 

Sorry for the delay in response, somehow I missed this. 
Those were SVN IDs. I have created a github id (vvenkatesan)  
vvenkates is the currently active SVN ID. So

vvenkates -> vvenkatesan

Thanks
Vish

On Sep 18, 2014, at 10:58 AM, "Jeff Squyres (jsquyres)"  
wrote:

On Sep 18, 2014, at 11:35 AM, Vishwanath Venkatesan  
wrote:

       > I seem to have two ids, vvenkates and vvenkatesan
       > I prefer to keep vvenkatesan

Are you referring to your Github or SVN IDs?


       > Thanks
       > Vish
       > 
       > On Sep 18, 2014, at 06:34 AM, Alina Sklarevich  wrote:
       > 
       >        > ompimtttester
       >        > 
       >        > On Thu, Sep 18, 2014 at 11:38 AM, Alex Margolin  wrote:

       >        > alex -  > alex-ma
       >        > alinas -      > alinask
       >        > amikheev -  > alex-mikheev
       >        > 
       >        > vasily -      > vasilyMellanox
       >        > 
       >        > 
       >        > 
       >        > On Wed, Sep 10, 2014 at 1:46 PM, Jeff Squyres (jsquyres)  wrote:

       >        > As the next step of the planned migration to Github, I need 
to know:
       >        > 
       >        > - Your Github ID (so that you can be added to the new OMPI git repo)

       >        > - Your SVN ID (so that I can map SVN-    >Github IDs, and 
therefore map Trac tickets to appropriate owners)
       >        > 
       >        > Here's the list of SVN IDs who have committed over the past year -- I'm guessing that most of these people will need Github IDs:
       >        > 
       >        > adrian

       >        > alekseys
       >        > alex
       >        > alinas
       >        > amikheev
       >        > bbenton
       >        > bosilca (done)
       >        > bouteill
       >        > brbarret
       >        > bwesarg
       >        > devendar
       >        > dgoodell (done)
       >        > edgar
       >        > eugene
       >        > ggouaillardet
       >        > hadi
       >        > hjelmn
       >        > hpcchris
       >        > hppritcha
       >        > igoru
       >        > jjhursey (done)
       >        > jladd
       >        > jroman
       >        > jsquyres (done)
       >        > jurenz
       >        > kliteyn
       >        > manjugv
       >        > miked (done)
       >        > mjbhaskar
       >        > mpiteam (done)
       >        > naughtont
       >        > osvegis
       >        > pasha
       >        > regrant
       >        > rfaucett
       >        > rhc (done)
       >        > rolfv (done)
       >        > samuel
       >        > shiqing
       >        > swise
       >        > tkordenbrock
       >        > vasily
       >        > vvenkates
       >        > vvenkatesan
       >        > yaeld
       >        > yosefe
       >        > 
       >        > --

       >        > 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
       >        > Subscription: 
http://www.open-mpi.org/mailman/listinfo.cgi/devel
       >        > Link to this post: 
http://www.open-mpi.org/community/lists/devel/2014/09/15788.php
       >        > 
       >        > 
       >        > ___

       >        > devel mailing list
       >        > de...@open-mpi.org
       >        > Subscription: 
http://www.open-mpi.org/mailman/listinfo.cgi/devel
       >        > Link to this post: 
http://www.open-mpi.org/community/lists/devel/2014/09/15864.php
       >        > 
       >        > ___

       >        > devel mailing list
       >        > de...@open-mpi.org
       >        > Subscription: 
http://www.open-mpi.org/mailman/listinfo.cgi/devel
       >        > Link to this post: 
http://www.open-mpi.org/community/lists/devel/2014/09/15866.php
       > ___
       > devel mailing list
       > de...@open-mpi.org
       > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
       > Link to this post: 
http://www.open-mpi.org/community/lists/devel/2014/09/15876.php


--
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
Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
Link to this post: 
http://www.open-mpi.org/community/lists/devel/2014/09/15877.php

Re: [hwloc-devel] Using hwloc to detect Hard Disks

2014-09-23 Thread Pedaballe, Vineet 
Thank you Ralph and Jeff. 

This was the list I was hoping to read through hwloc.

3. Memory
a. Total memory
b. Total DIMMS
c. Individual DIMM's:
(i) Serial numbers
(ii) Vendor Name
(iii) Model
(iv) Memory Frequency
4a. Network Adapters (Ethernet)
a. Model
b. Speed
c. Serial Number (if applicable)
d. MAC address
4b. Network Adapters (Infiniband)
a. Model
b. Speed
c. Serial Number (if applicable)
d. MAC address
4. Host Bus Adapters
a. Manufacturer
b. Serial Number
c. MAC address
6. Coprocessors
a. Manufacturer
b. Serial Number
7. Other PCI Devices
a. Device ID
b. Device Serial number (if applicable)
8. HardDrive
a. Model, Form factor, etc.
b. Vendor
c. Serial Number
d. Size


Some of it is already provided by HWLOC. For some other items, a limited set of 
information is provided by HWLOC.

Most of the DIMM related data is provided by the SMBIOS tables. 'dmidecode' 
provides a lot of this information.
The application hdparm provides a lot of information about hard drives. I 
glanced over their code, and it seems like they also udev to retrieve the 
information.


* For Memory, I would suggest have a single object for each node and list the 
DIMM details as attributes for that object.
* For hard drives, we can have similar objects for each SATA0.., etc node, 
whose lanes are usually connected via the PCH to a single socket. Each hard 
drive can have its own object, and all the attributes of the hard drive can be 
stored within that object.
* For the PCI devices I understand it is not simple to read the serial number 
and UUID details, but I know how to read the serial numbers for some 
products(like the Intel coprocessors) and it would be really cool to add this 
also as an attribute to it.

I'm still not entirely familiar with the hwloc's internal architecture, I 
apologize in case I make any wrong assumptions.
How would you like me to proceed from here?

Thanks,
Vineet

-Original Message-
From: hwloc-devel [mailto:hwloc-devel-boun...@open-mpi.org] On Behalf Of Brice 
Goglin
Sent: Tuesday, September 23, 2014 8:48 AM
To: hwloc-de...@open-mpi.org
Subject: Re: [hwloc-devel] Using hwloc to detect Hard Disks

Le 23/09/2014 16:46, Brice Goglin a écrit :
> Le 23/09/2014 16:38, Guy Streeter a écrit :
>> I know that udev gathers this information:
>>
>> # ll /sys/block/sda/bdi
>> lrwxrwxrwx. 1 root root 0 Sep 23 09:33 /sys/block/sda/bdi ->
>> ../../../../../../../../virtual/bdi/8:0
>> # grep SERIAL '/run/udev/data/b8:0'
>> E:ID_SERIAL=SAMSUNG_MZ7TD256HAFV-000L9_S17LNSADC13325
>> E:ID_SERIAL_SHORT=S17LNSADC13325
>>
>> So you could get it from udev or gather it the same way udev does. If 
>> you want to know how udev does it, I can research that.
> If you can get more information, that'd be great. I wonder if they are 
> using ioctls to retrieve these, I can't find anything in sysfs even 
> though udev has similar info on my machines.
>

Indeed there's a struct hd_driveid in linux/hdreg.h that you get with ioctl 
HDIO_GET_IDENTITY on the device.

There's also a libblkid that may help.

Brice

___
hwloc-devel mailing list
hwloc-de...@open-mpi.org
Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
Link to this post: 
http://www.open-mpi.org/community/lists/hwloc-devel/2014/09/4235.php

[OMPI devel] Conversion to GitHub: tomorrow (Sep 24, 2014)

2014-09-23 Thread Jeff Squyres (jsquyres) 
REMINDER: The conversion of Open MPI's Subversion repository and Trac tickets 
will be happening tomorrow, Wednesday, September 24, 2014.

SVN and Trac will be going read-only at 8am US Eastern tomorrow, and the 
conversion process will begin.  I anticipate it taking all day.

I'll send an "all clear" email when I'm all finished, along with additional 
details.

You should probably go read up on how we're going to use GitHub:

https://github.com/open-mpi/ompi/wiki

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

Re: [hwloc-devel] Using hwloc to detect Hard Disks

2014-09-23 Thread Brice Goglin 
Le 23/09/2014 16:46, Brice Goglin a écrit :
> Le 23/09/2014 16:38, Guy Streeter a écrit :
>> I know that udev gathers this information:
>>
>> # ll /sys/block/sda/bdi
>> lrwxrwxrwx. 1 root root 0 Sep 23 09:33 /sys/block/sda/bdi ->
>> ../../../../../../../../virtual/bdi/8:0
>> # grep SERIAL '/run/udev/data/b8:0'
>> E:ID_SERIAL=SAMSUNG_MZ7TD256HAFV-000L9_S17LNSADC13325
>> E:ID_SERIAL_SHORT=S17LNSADC13325
>>
>> So you could get it from udev or gather it the same way udev does. If you
>> want to know how udev does it, I can research that.
> If you can get more information, that'd be great. I wonder if they are
> using ioctls to retrieve these, I can't find anything in sysfs even
> though udev has similar info on my machines.
>

Indeed there's a struct hd_driveid in linux/hdreg.h that you get with
ioctl HDIO_GET_IDENTITY on the device.

There's also a libblkid that may help.

Brice

Re: [hwloc-devel] Using hwloc to detect Hard Disks

2014-09-23 Thread Ralph Castain 
Memory info is available from lshw, though they are a GPL code:

 *-bank:0
  description: DIMM Synchronous 1333 MHz (0.8 ns)
  product: M393B1K70DH0-YH9
  vendor: 0x80CE
  physical id: 0
  serial: 0x85B5FED3
  slot: DIMM_A1
  size: 8GiB
  width: 64 bits
  clock: 1333MHz (0.8ns)

Not sure how they are getting it, but I can have someone look at the code to 
see where the info is being obtained.


On Sep 22, 2014, at 8:54 PM, Ralph Castain  wrote:

> 
> On Sep 22, 2014, at 4:58 PM, Jeff Squyres (jsquyres)  
> wrote:
> 
>> On Sep 22, 2014, at 6:55 PM, Brice Goglin  wrote:
>> 
 HWLOC already provides similar info for processors and mother boards, so 
 it seemed a natural extension of current capabilities to provide it for 
 other system elements.
>>> 
>>> Disk vendor/model is easy to add from sysfs on Linux. I don't know where
>>> to find the serial number. Spindle speed may require more than just
>>> sysfs. Do you have more info on how to get these attributes?
>>> 
>>> For memory, we currently have a single memory object for all DIMMs of a
>>> single NUMA node. Adding multiple objects may not be useful, but adding
>>> many serials to a single NUMA object may be ugly.
>>> There are some information about physical memory in
>>> /sys/devices/system/node/node0/memory* but it doesn't correspond to
>>> DIMMs (I have 135 of them on my laptop for only 2 SODIMMs). dmidecode
>>> gets DIMM info somehow.
>> 
>> Back in Nehalem days, it wasn't possible to map Linux kernel "physical" 
>> memory back to individual DIMMs (because the BIOS could/would introduce 
>> another layer of kernel<-->DIMM mapping that the kernel might not be aware 
>> of).
>> 
>> Has that changed?
> 
> I don't think so, no - at least, I'm not sure you can map a specific DIMM to 
> a specific address within a NUMA region. However, we can at least add the 
> DIMMs to the root-object attributes. In addition, you can certainly map a 
> DIMM to a specific DIMM socket, and I believe that means you can map it to a 
> given NUMA region even if you can't say *where* it is within that region. 
> Have to verify that.
> 
> 
>> 
>> -- 
>> Jeff Squyres
>> jsquy...@cisco.com
>> For corporate legal information go to: 
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>> 
>> ___
>> hwloc-devel mailing list
>> hwloc-de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>> Link to this post: 
>> http://www.open-mpi.org/community/lists/hwloc-devel/2014/09/4229.php

Re: [hwloc-devel] Using hwloc to detect Hard Disks

2014-09-23 Thread Brice Goglin 
Le 23/09/2014 16:38, Guy Streeter a écrit :
> I know that udev gathers this information:
>
> # ll /sys/block/sda/bdi
> lrwxrwxrwx. 1 root root 0 Sep 23 09:33 /sys/block/sda/bdi ->
> ../../../../../../../../virtual/bdi/8:0
> # grep SERIAL '/run/udev/data/b8:0'
> E:ID_SERIAL=SAMSUNG_MZ7TD256HAFV-000L9_S17LNSADC13325
> E:ID_SERIAL_SHORT=S17LNSADC13325
>
> So you could get it from udev or gather it the same way udev does. If you
> want to know how udev does it, I can research that.

If you can get more information, that'd be great. I wonder if they are
using ioctls to retrieve these, I can't find anything in sysfs even
though udev has similar info on my machines.

Brice

Re: [OMPI devel] opal components still #including OMPI header files

2014-09-23 Thread Jeff Squyres (jsquyres) 
Rolf -- please add this to the agenda for today.

On Sep 23, 2014, at 10:28 AM, Ralph Castain  wrote:

> ofacm needs to be updated to remove xoob and oob modules as those cannot be 
> used from the opal layer
> 
> 
> On Sep 23, 2014, at 7:22 AM, Jeff Squyres (jsquyres)  
> wrote:
> 
>> From SVN trunk HEAD (r32772):
>> 
>> -
>> mca/btl/ugni/btl_ugni_component.c
>> 20:#include "ompi/runtime/params.h"
>> 
>> mca/btl/usnic/btl_usnic_compat.h
>> 43:#  include "ompi/mca/rte/rte.h"
>> --> This is ok; it is protected in a #if (just to make diffs to v1.8 easier)
>> 
>> mca/common/ofacm/common_ofacm_xoob.c
>> 26:#include "ompi/mca/rte/rte.h"
>> 
>> mca/common/ofacm/common_ofacm_oob.c
>> 37:#include "ompi/mca/rte/rte.h"
>> 
>> mca/mpool/sm/mpool_sm_module.c
>> 36:#include "ompi/runtime/ompi_cr.h" /* TODO */
>> -
>> 
>> -- 
>> 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
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post: 
>> http://www.open-mpi.org/community/lists/devel/2014/09/15901.php
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/09/15902.php


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

Re: [OMPI devel] opal components still #including OMPI header files

2014-09-23 Thread Ralph Castain 
ofacm needs to be updated to remove xoob and oob modules as those cannot be 
used from the opal layer


On Sep 23, 2014, at 7:22 AM, Jeff Squyres (jsquyres)  wrote:

> From SVN trunk HEAD (r32772):
> 
> -
> mca/btl/ugni/btl_ugni_component.c
> 20:#include "ompi/runtime/params.h"
> 
> mca/btl/usnic/btl_usnic_compat.h
> 43:#  include "ompi/mca/rte/rte.h"
> --> This is ok; it is protected in a #if (just to make diffs to v1.8 easier)
> 
> mca/common/ofacm/common_ofacm_xoob.c
> 26:#include "ompi/mca/rte/rte.h"
> 
> mca/common/ofacm/common_ofacm_oob.c
> 37:#include "ompi/mca/rte/rte.h"
> 
> mca/mpool/sm/mpool_sm_module.c
> 36:#include "ompi/runtime/ompi_cr.h" /* TODO */
> -
> 
> -- 
> 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
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/09/15901.php

Re: [OMPI devel] race condition in oob/tcp

2014-09-23 Thread Ralph Castain 
Thanks! I won't have time to work on it this week, but appreciate your effort. 
Also, thanks for clarifying the race condition vis 1.8 - I agree it is not a 
blocker for that release.

Ralph

On Sep 22, 2014, at 4:49 PM, Gilles Gouaillardet 
 wrote:

> Ralph,
> 
> here is the patch i am using so far.
> i will resume working on this from Wednesday (there is at least one remaining 
> race condition yet) unless you have the time to take care of it today.
> 
> so far, the race condition has only been observed in real life with the 
> grpcomm/rcd module, and this is not the default in v1.8, so imho this is not 
> a blocker for v1.8.3
> 
> Cheers,
> 
> Gilles
> 
> On Tue, Sep 23, 2014 at 7:46 AM, Ralph Castain  wrote:
> Gilles - please let me know if/when you think you'll do this. I'm debating 
> about adding it to 1.8.3, but don't want to delay that release too long. 
> Alternatively, I can take care of it if you don't have time (I'm asking if 
> you can do it solely because you have the reproducer).
> 
> 
> On Sep 21, 2014, at 6:54 AM, Ralph Castain  wrote:
> 
>> Sounds fine with me - please go ahead, and thanks
>> 
>> On Sep 20, 2014, at 10:26 PM, Gilles Gouaillardet 
>>  wrote:
>> 
>>> Thanks for the pointer George !
>>> 
>>> On Sat, Sep 20, 2014 at 5:46 AM, George Bosilca  wrote:
>>> Or copy the handshake protocol design of the TCP BTL...
>>> 
>>> 
>>> the main difference between oob/tcp and btl/tcp is the way we resolve the 
>>> situation in which two processes send their first message to each other at 
>>> the same time.
>>> 
>>> in oob/tcp, all (e.g. one or two) sockets are closed and the higher vpid is 
>>> directed to retry establishing a connection.
>>> 
>>> in btl/tcp, the useless socket is closed (e.g. the one that was connect-ed 
>>> on the lower vpid and the one that was accept-ed on the higher vpid.
>>> 
>>> 
>>> my first impression is that oob/tcp is un-necessary complex and it should 
>>> use the simpler and most efficient protocol of btl/tcp.
>>> that being said, this conclusion could be too naive and for some good 
>>> reasons i ignore, the btl/tcp handshake protocol might not be a good fit 
>>> for oob/tcp.
>>> 
>>> any thoughts ?
>>> 
>>> i will revamp oob/tcp in order to use the same btl/tcp handshake protocol 
>>> from tomorrow unless indicated otherwise
>>> 
>>> Cheers,
>>> 
>>> Gilles
>>> ___
>>> devel mailing list
>>> de...@open-mpi.org
>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>> Link to this post: 
>>> http://www.open-mpi.org/community/lists/devel/2014/09/15885.php
>> 
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/09/15895.php
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2014/09/15897.php

Re: [hwloc-devel] Using hwloc to detect Hard Disks

2014-09-23 Thread Ralph Castain 

On Sep 22, 2014, at 4:58 PM, Jeff Squyres (jsquyres)  wrote:

> On Sep 22, 2014, at 6:55 PM, Brice Goglin  wrote:
> 
>>> HWLOC already provides similar info for processors and mother boards, so it 
>>> seemed a natural extension of current capabilities to provide it for other 
>>> system elements.
>> 
>> Disk vendor/model is easy to add from sysfs on Linux. I don't know where
>> to find the serial number. Spindle speed may require more than just
>> sysfs. Do you have more info on how to get these attributes?
>> 
>> For memory, we currently have a single memory object for all DIMMs of a
>> single NUMA node. Adding multiple objects may not be useful, but adding
>> many serials to a single NUMA object may be ugly.
>> There are some information about physical memory in
>> /sys/devices/system/node/node0/memory* but it doesn't correspond to
>> DIMMs (I have 135 of them on my laptop for only 2 SODIMMs). dmidecode
>> gets DIMM info somehow.
> 
> Back in Nehalem days, it wasn't possible to map Linux kernel "physical" 
> memory back to individual DIMMs (because the BIOS could/would introduce 
> another layer of kernel<-->DIMM mapping that the kernel might not be aware 
> of).
> 
> Has that changed?

I don't think so, no - at least, I'm not sure you can map a specific DIMM to a 
specific address within a NUMA region. However, we can at least add the DIMMs 
to the root-object attributes. In addition, you can certainly map a DIMM to a 
specific DIMM socket, and I believe that means you can map it to a given NUMA 
region even if you can't say *where* it is within that region. Have to verify 
that.


> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> ___
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/hwloc-devel/2014/09/4229.php