[hwloc-devel] v1.11.0

Hi folks I’ve been working on updating the OMPI hwloc code to the 1.11 version. I reported via Jeff about the config issue, so I updated to the latest nightly tarball of 1.11 to pickup that change. I’m now able to configure, but hit one last required change to make it build: diff --git

Re: [hwloc-devel] hwloc failures

FWIW: I just downloaded and build 1.10.0 without problem on Mac Yosemite using GCC. I have the Darwin ports libxml2 installed - version 2.9.2. > On Nov 19, 2014, at 1:28 PM, Brice Goglin wrote: > > Which version of libxml2 do you have? > > Brice > > > > > Le

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

True - but we intend to collect the inventory as root anyway. :-) On Sep 23, 2014, at 1:50 PM, Christopher Samuel <sam...@unimelb.edu.au> wrote: > On 24/09/14 00:57, Ralph Castain wrote: > >> Memory info is available from lshw, though they are a GPL code: > > FWIW on th

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

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 <r...@open-mpi.org> wrote: > > On Sep 22, 2014, at 4:58 PM, Jeff Squyr

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

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

Re: [hwloc-devel] Interesting warning

Yep, that worked! On Sep 12, 2014, at 1:30 AM, Samuel Thibault <samuel.thiba...@inria.fr> wrote: > Hello, > > Ralph Castain, le Wed 10 Sep 2014 17:41:17 -0700, a écrit : >> Just got this from Clang 3.4.2 on Linux x86-64: >> >> In file included from topology-

[hwloc-devel] Interesting warning

Just got this from Clang 3.4.2 on Linux x86-64: In file included from topology-x86.c:23: /home/common/openmpi/svn-trunk/opal/mca/hwloc/hwloc191/hwloc/include/private/cpuid-x86.h:67:3: warning: extension used [-Wlanguage-extension-token] asm( ^ 1 warning generated. Guess it doesn't like

Re: [hwloc-devel] GIT: hwloc branch master updated. 0e6fe307c10d47efee3fb95c50aee9c0f01bc8ec

Jeff just left today for a 1-week vacation. However, this came up on the OMPI mailing list - turns out that some linux distro's automatically set LS_COLORS in your environment when running old versions of csh/tcsh via their default dot files, and it can cause problems with the script. So just

Re: [hwloc-devel] Attribute request

odelNumber=1 >> CPUFamilyNumber=32 >> * AMD >> CPUVendor=AuthenticAMD >> CPUModel=Dual Core AMD Opteron(tm) Processor 865 >> CPUModelNumber=33 >> CPUFamilyNumber=15 >> * MIC (Stampede) >> CPUVendor=GenuineIntel >> CPUModel=0b/01 >> CPUModelNumber=1 >>

Re: [hwloc-devel] Attribute request

CPUFamilyNumber=11 Le 23/01/2014 19:50, Ralph Castain a écrit : > That would be perfect! Thanks > > On Jan 23, 2014, at 10:27 AM, Brice Goglin <brice.gog...@inria.fr> wrote: > >> Should be easy on Linux, sure. >> The model name is already known as CPUModel in hwloc. >> W

Re: [hwloc-devel] Attribute request

), > CPUFamily (or CPUFamilyNumber if there's a name for these families?) and > CPUModelNumber ? > > Brice > > > > > Le 23/01/2014 19:09, Ralph Castain a écrit : >> Hi folks >> >> Looking at the current topology info, I see you capture the model name for >>

[hwloc-devel] Attribute request

Hi folks Looking at the current topology info, I see you capture the model name for the socket, but not a couple of other key things Intel could use: cpu family : 6 model : 44 model name : Intel(R) Xeon(R) CPU E5645 @ 2.40GHz Both the cpu family and model are

[hwloc-devel] Support for new architecture

Hi folks We are seeing a new architecture appearing in the very near future, and I'm not sure how hwloc will handle it. Consider the following case: * I have a rack that contains multiple "hosts" * each host consists of a box/shelf with common support infrastructure in it - it has some kind

[hwloc-devel] Strange difference

Yo guys I was doing some work that involved traversing the hwloc topo tree, and encountered the following odd discrepancy. hwloc_topology_get_depth => returns "unsigned" hwloc_get_type_depth => returns "int" Why the difference? Makes it hard sometimes to avoid the "comparison between

Re: [hwloc-devel] xml file load incompatibilities

ooks total crazy, I don't see how debug checks > could still pass in that case. > Any chance you valgrind that thing? > > Brice > > > > Le 21/09/2013 01:09, Ralph Castain a écrit : >> Hmmm...nope, not a peep (no extra output at all). Just segfaulted like >

Re: [hwloc-devel] xml file load incompatibilities

) > > Brice > > > > Le 21/09/2013 01:03, Ralph Castain a écrit : >> I didn't try loading it with lstopo - just tried the OMPI trunk. It loads >> okay, but segfaults when you try to find an object by depth >> >> #0 0x0001005fe5dc in opal_hwloc172_hwl

Re: [hwloc-devel] xml file load incompatibilities

in > case the bug is in one of XML backends), looks ok. > > Brice > > > > > > Le 20/09/2013 23:53, Ralph Castain a écrit : >> Here are the two files I tried - not from the same machine. The foo.xml >> works, the topo.xml segfaults >> >>

Re: [hwloc-devel] xml file load incompatibilities

our machines? > Brice > > > > Le 20/09/2013 23:32, Ralph Castain a écrit : >> Hi folks >> >> I've run across a rather strange behavior. We have two branches in OMPI - >> the devel trunk (using hwloc v1.7.2) and our feature release series (using >> hwloc

[hwloc-devel] xml file load incompatibilities

Hi folks I've run across a rather strange behavior. We have two branches in OMPI - the devel trunk (using hwloc v1.7.2) and our feature release series (using hwloc 1.5.2). I have found the following: *the feature series can correctly load an xml file generated by lstopo of versions 1.5 or

Re: [hwloc-devel] v1.7

On Jan 7, 2013, at 6:05 AM, Samuel Thibault wrote: > Hello, > > Brice Goglin, le Mon 31 Dec 2012 10:05:41 +0100, a écrit : >> + The HWLOC_COMPONENTS may now start with '^' to only define a list of >> components to exclude. > > I'm finding it not intuitive and not

Re: [hwloc-devel] Cgroup resource limits

On Nov 4, 2012, at 7:28 PM, Christopher Samuel <sam...@unimelb.edu.au> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 03/11/12 09:05, Ralph Castain wrote: > >> System resource managers don't usually provide this capability, so >> we will do i

Re: [hwloc-devel] Cgroup resource limits

for this? Linux cgroups? Any concrete example of what you > would like to do? > > Brice > > > > Le 02/11/2012 22:12, Ralph Castain a écrit : >> Hi folks >> >> We (Greenplum) have a need to support resource limits (e.g., memory and cpu >> usage) on p

[hwloc-devel] Cgroup resource limits

Hi folks We (Greenplum) have a need to support resource limits (e.g., memory and cpu usage) on processes running under Open MPI's RTE. OMPI uses hwloc for processor and memory affinity, so this seems a likely place to add the required support. Jeff tells me that it doesn't yet exist in hwloc -

Re: [hwloc-devel] lstopo-nox strikes back

I don't have a strong opinion, but the historical "standard practice" for Linux/Unix has always been to default to cmd line, non-graphical interfaces. Graphical output was optional. Of course, that stemmed from the days before everyone had a graphical display, but it is still generally

Re: [hwloc-devel] hwloc + OMPI issue

Thanks! I'll add the latter to our code. Ralph On Oct 12, 2011, at 3:11 PM, Brice Goglin wrote: > Le 12/10/2011 22:56, Jeff Squyres a écrit : >> One of the OMPI devs found a problem when I upgraded the OMPI SVN trunk to >> the hwloc 1.2.2ompi version last week that I think I am just now

Re: [hwloc-devel] 1.3 -- wait!

On Oct 11, 2011, at 7:34 AM, Brice Goglin wrote: > Le 11/10/2011 15:04, Jeff Squyres a écrit : >> Looks like Ralph's size/linesize patch didn't make it to v1.3: >> >> Index: src/traversal.c >> === >> --- src/traversal.c (revision

Re: [hwloc-devel] Something lighter-weight than XML?

ms on your dual-amd machine > (those have distance matrices) and not on your mac (single processor, no > distances, no bug). > > The v1.2 branch doesn't report parsing failure well, so it just crashed. > Trunk exits with an error instead of crashing. > > Brice > >

Re: [hwloc-devel] Something lighter-weight than XML?

; > Le 24/09/2011 20:37, Ralph Castain a écrit : >> Yep, it fails. Runs on my Mac, but not under Linux. >> >> Program terminated with signal 11, Segmentation fault. >> #0 0x2acdbedd in hwloc_bitmap_snprintf () from >> /nfs/rinfs/san/homedirs/rhc/lib/lib

Re: [hwloc-devel] Something lighter-weight than XML?

it fails on one of the machines you're using here. > > https://svn.open-mpi.org/trac/hwloc/browser/branches/v1.2-ompi/tests/xmlbuffer.c?rev=3837=txt > > thanks > Brice > > > > Le 24/09/2011 17:07, Ralph Castain a écrit : >> FWIW: I tried just printing out the co

Re: [hwloc-devel] Something lighter-weight than XML?

} On Sep 24, 2011, at 9:02 AM, Ralph Castain wrote: > Here's the trace: > > #0 0x2ae61737 in hwloc__xml_export_object (output=0x7fffd890, > topology=0x695f10, obj=0x2b139b28) >at topology-xml.c:1094 > #1 0x2ae61b69 in hwloc___nolibxml_prepar

Re: [hwloc-devel] Something lighter-weight than XML?

Here's the trace: #0 0x2ae61737 in hwloc__xml_export_object (output=0x7fffd890, topology=0x695f10, obj=0x2b139b28) at topology-xml.c:1094 #1 0x2ae61b69 in hwloc___nolibxml_prepare_export (topology=0x695f10, xmlbuffer=0x698a70 "\n\n\n

Re: [hwloc-devel] Some practical hwloc API feedback

On Sep 24, 2011, at 5:52 AM, Jeff Squyres wrote: > On Sep 24, 2011, at 7:46 AM, Jeff Squyres wrote: > >>> The funky thing here is that the parent/child links between the first >>> socket and its core go across level 2 because nothing matches there. In >>> the first socket, you have

Re: [hwloc-devel] Some practical hwloc API feedback

On Sep 22, 2011, at 3:05 PM, Brice Goglin wrote: > Le 22/09/2011 22:42, Ralph Castain a écrit : >> I guess I didn't get that from your documentation. Since caches sit >> between socket and core, they appear to affect the depth of the core >> in a given socket. Thus, i

Re: [hwloc-devel] Patch for hwloc_obj_attr_snprintf

Resending - had to join list! Oh - I should have noted that I took the labels directly from the xml output. So cachesize and cacheline are what you have in the xml output. I don't care if they match, though - just pointing it out. On Sep 22, 2011, at 1:59