Re: [OMPI devel] 32 bit issues (was: 32 bit support needs a maintainer)

Hello This seems to be the code for sharing the hwloc topology in shared memory. This whole thing was designed for very large virtual spaces (>=48bits on most CPUs) where it's easy to find a virtual memory area that is unused in all participating processes. I am not sure it's worth fixing on

[hwloc-devel] hwloc 3.0 breaking the ABI again?

Hello hwloc 2.0 was released 4 years ago and this major release was painful because it broke the ABI and significantly changed the API. I want to avoid having users modify their code with #ifdef again. But there is at least one good reason to break the ABI in the future (support for 32bits

Re: [OMPI devel] v5.0 equivalent of --map-by numa

Hello Ben It will be back, at least for the majority of platforms (those without heterogeneous memory). See https://github.com/open-mpi/ompi/issues/8170 and https://github.com/openpmix/prrte/pull/1141 Brice Le 11/11/2021 à 05:33, Ben Menadue via devel a écrit : Hi, Quick question:

Re: [hwloc-devel] Negative values for die_id and physical_package_id

Le 26/05/2021 à 15:23, Samuel Thibault a écrit : Brice Goglin, le mer. 26 mai 2021 14:13:02 +0200, a ecrit: os_index is already *unsigned* in the API (did you mean signed?). We cannot change the obj->os_index back to signed now, it would break existing users. Mmm, it wouldn't break the

Re: [hwloc-devel] Negative values for die_id and physical_package_id

Le 26/05/2021 à 14:24, Jirka Hladky a écrit :  However maybe debugging would be easier if tools printed that special value as -1 instead of 4294967295 (I'd need to check other tools too, lstopo takes care of some of these values, maybe not all). I agree.  So perhaps we can update

Re: [hwloc-devel] Negative values for die_id and physical_package_id

Le 26/05/2021 à 13:51, Jirka Hladky a écrit : Hi Brice, I would like to get your opinion on the following issue. On IBM LPAR, kernel reports  die_id and physical_package_id to be -1. See [0] hwloc-calc converts these values into an unsigned integer, resulting in Socket ID 2^32-1:

Re: [hwloc-devel] hwloc on IBM Power LPAR VMs

r. Brice commit 7c159d723432e461b4e48cc2d38212913d2ba7c7 Author: Brice Goglin Date: Mon Apr 26 20:35:42 2021 +0200 linux: fix support for NUMA node0 being oddline Just like we didn't support offline CPU#0 until commit 7bcc273efd50536961ba16d474efca4ae163229b, we need to

Re: [hwloc-devel] hwloc on IBM Power LPAR VMs

Hello, Maybe we have something that assumes that the first NUMA node on Linux is #0. And something is wrong in the disallowed case anyway since the NUMA node physical number is 0 instead of 2 there. Can you run "hwloc-gather-topology lpar" and send the resulting lpar.tar.bz2? (send it only

Re: [OMPI devel] HWLOC duplication relief

ary detect that the shmem >>> region has already been mapped? If we attempt to map it and fail, does that >>> mean it has already been mapped or that it doesn't exist? >>> >>> It isn't reasonable to expect that all the libraries in a process will >>> coord

Re: [OMPI devel] HWLOC duplication relief

Hello Ralph One thing that isn't clear in this document : the hwloc shmem region may only be mapped *once* per process (because the mmap address is always the same). Hence, if a library calls adopt() in the process, others will fail. This applies to the 2nd and 3rd case in "Accessing the HWLOC

Re: [OMPI devel] Git submodules are coming

FYI, this was a git bug that will be fixed soon (the range of commits being rebased was wrong). https://lore.kernel.org/git/pull.789.git.1605314085.gitgitgad...@gmail.com/T/#t https://lore.kernel.org/git/20d6104d-ca02-4ce4-a1c0-2f9386ded...@gmail.com/T/#t Brice Le 07/02/2020 à 10:27, Brice

Re: [OMPI devel] Git submodules are coming

Hello I have a git submodule issue that I don't understand. PR#7367 was initially on top of PR #7366. When Jeff merged PR#7366, I rebased my #7367 with git prrs and got this error: $ git prrs origin master >From https://github.com/open-mpi/ompi  * branch  master ->

Re: [OMPI devel] Git submodules are coming

Thanks a lot for writing all this. At the end https://github.com/open-mpi/ompi/wiki/GitSubmodules#adding-a-new-submodule-pointing-to-a-specific-commit should "bar" be "bar50x" in line "$ git add bar" ? It seems to me that you are in opal/mca/foo and the new submodule is in "bar50x" (according

Re: [hwloc-devel] Strange CPU topology numbering on dual socket ARM server with 2×ThunderX2 CN9975

Hello Jirka I don't think there's a bug here. physical_package_id don't have to be between 0 and N-1, they just have to be different to identify packages and cores between packages. Having other values is uncommon on x86 but quite common on POWER at least. core_id is even worse. They are

[hwloc-devel] Signed-off-by in commits now required

Hello Starting today, we require that all hwloc commits have a Signed-off-by line with your employer email. Our Github repo is not configured to actually reject non-signed commits [1] , please try to include that line so that we don't have to revert some commits later. See what this line means

Re: [OMPI devel] Gentle reminder: sign up for the face to face

Hello Jeff Looks like I am not allowed to modify the page but I'll be at the meeting ;) Brice Le 26/02/2019 à 17:13, Jeff Squyres (jsquyres) via devel a écrit : > Gentle reminder to please sign up for the face-to-face meeting and add your > items to the wiki: > >

Re: [hwloc-devel] HWLOC - Memory bind

Hello Which hwloc release are you using? Before hwloc 2.0, libnuma/numactl devel headers were required for memory binding. The end of the output of "configure" will tell you whether memory binding is supported when building such an old release:

Re: [hwloc-devel] hwloc_distances_add conflicting declaration

Hello We now have a CI slave running cygwin on Windows 10. Everything should work fine in v2.0.3. In the meantime, the only patch that you need to add on top of what you sent earlier is: https://github.com/open-mpi/hwloc/commit/3ac7bd3b3bddd763b2e58eff77a2104ea79230af (for fixing

Re: [hwloc-devel] hwloc_distances_add conflicting declaration

OK I pushed your #ifdef fixes and I fixed the printf warning. I opened 3 issues related to x86 cpuid and OpenProcess failing in lstopo --ps. Hopefully we'll find a way to play with cygwin here for real in the near future, and then add that config to our CI. Brice

Re: [hwloc-devel] hwloc_distances_add conflicting declaration

Le 02/10/2018 à 00:28, Marco Atzeri a écrit : > Am 01.10.2018 um 19:57 schrieb Brice Goglin: >> Le 01/10/2018 à 19:22, Marco Atzeri a écrit : >>> >> >> Your own machine doesn't matter. None is these tests look at your CPU or >> topology. *All* of them on all

Re: [hwloc-devel] hwloc_distances_add conflicting declaration

Le 01/10/2018 à 19:22, Marco Atzeri a écrit : > >> Unfortunately that test script isn't easy to debug in the v2.x branch. >> If that OpenProcess is where things fail, I assume that the line that >> fails is "lstopo --ps". On MinGW, that code is ignored because /proc >> doesn't exist. Does /proc

Re: [hwloc-devel] hwloc_distances_add conflicting declaration

Le 01/10/2018 à 17:27, Marco Atzeri a écrit : > Am 30.09.2018 um 20:11 schrieb Samuel Thibault: >> Marco Atzeri, le dim. 30 sept. 2018 20:02:59 +0200, a ecrit: >>> also adding a HWLOC_DECLSPEC on the first case distances.c:347 >>> does not solve the issue as the two declaration are not the same.

Re: [hwloc-devel] [PATCH] topology-x86: add support for Hygon Dhyana Family 18h processor

Thanks a lot, the code looks good. I pushed it to master. I'll backport to stable branches once you'll send cpuid dumps for regression testing :) Did you test the code by forcing hwloc's x86 backend with HWLOC_COMPONENTS=x86? Otherwise hwloc uses the Linux backend by default (which reads sysfs),

Re: [OMPI devel] About supporting HWLOC 2.0.x

I just pushed my patches rebased on master + update to hwloc 2.0.1 to bgoglin/ompi (master branch). My testing of mapping/ranking/binding looks good here (on dual xeon with CoD, 2 sockets x 2 NUMA x 6 cores). It'd be nice if somebody else could test on another platform with different options

Re: [OMPI devel] About supporting HWLOC 2.0.x

Sorry guys, I think I have all patches ready since the F2F meeting, but I couldn't test them enough because ranking was broken. I'll work on that by next week. Brie Le 22/05/2018 à 17:50, r...@open-mpi.org a écrit : > I’ve been running with hwloc 2.0.1 for quite some time now without problem,

[hwloc-devel] libhwloc soname change in 2.0.1rc1

Hello In case you missed the announce yesterday, hwloc 2.0.1rc1 changes the library soname from 12:0:0 to 15:0:0. On Linux, it means that we'll now build libhwloc.so.15 instead of libhwloc.so.12. That means any application built for hwloc 2.0.0 will need to be recompiled against 2.0.1. I should

Re: [hwloc-devel] [SCM] open-mpi/hwloc branch master updated. 14e727976867931a2eb74f2630b0ce9137182874

configure only looks for CL/cl_ext.h before enabling the OpenCL backend. Did it enable OpenCL on your machine? On my VMs, there's /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenCL.framework/Versions/A/Headers/cl_ext.h

[OMPI devel] hwloc issues in this week telcon?

Hello Two hwloc issues are listed in this week telcon: "hwloc2 WIP, may need help with." https://github.com/open-mpi/ompi/pull/4677 * Is this really a 3.0.1 thing? I thought hwloc2 was only for 3.1+ * As I replied in this PR, I have some patches but I need help for testing them. Can you list

Re: [hwloc-devel] No opencl osdev for NVidia GPU devices

Le 27/09/2017 à 20:39, Brice Goglin a écrit : > > Le 27/09/2017 18:58, Samuel Thibault a écrit : >> Hello, >> >> On systems with NVidia GPU devices, opencl devices don't show up in >> lstopo. Running in debug mode shows that they are detected: >> >&g

Re: [hwloc-devel] get_last_cpu_location for process (Was: Hardware locality (hwloc) v2.0.0-beta1 released)

Le 28/12/2017 à 19:20, Samuel Thibault a écrit : >> we can add a hwloc env var to disable process-wide asserts. > So I would set it for all Debian builds? (we don't have a fixed set of > archs which are built inside qemu-user) > Yes, if that's OK for you. I couldn't test since binding doesn't

Re: [hwloc-devel] get_last_cpu_location for process (Was: Hardware locality (hwloc) v2.0.0-beta1 released)

Le 28/12/2017 à 16:18, Samuel Thibault a écrit : > Samuel Thibault, on jeu. 28 déc. 2017 15:08:30 +0100, wrote: >> Samuel Thibault, on mer. 20 déc. 2017 18:32:48 +0100, wrote: >>> I have uploaded it to debian experimental, so when it passes NEW, >>> various arch test results will show up on >>>

Re: [hwloc-devel] [hwloc-announce] Hardware locality (hwloc) v2.0.0-beta1 released

Le 22/12/2017 à 11:42, Samuel Thibault a écrit : > Hello, > > Brice Goglin, on mar. 19 déc. 2017 11:48:39 +0100, wrote: >> + Memory, I/O and Misc objects are now stored in dedicated children lists, >> not in the usual children list that is now only used for

Re: [OMPI devel] hwloc2 and cuda and non-default cudatoolkit install location

Le 20/12/2017 à 22:01, Howard Pritchard a écrit : > > I can think of several ways to fix it.  Easiest would be to modify the > > opal/mca/hwloc/hwloc2a/configure.m4 > > to not set --enable-cuda if --with-cuda is evaluated to something > other than yes. > > > Optionally, I could fix the hwloc

Re: [hwloc-devel] [hwloc-announce] Hardware locality (hwloc) v2.0.0-beta1 released

:26, Samuel Thibault a écrit : > Brice Goglin, on mer. 20 déc. 2017 18:16:34 +0100, wrote: >> Le 20/12/2017 à 18:06, Samuel Thibault a écrit : >>> It has only one NUMA node, thus triggering the code I patched over. >> Well, this has been working fine for a while, since that's

Re: [hwloc-devel] [hwloc-announce] Hardware locality (hwloc) v2.0.0-beta1 released

Le 20/12/2017 à 18:06, Samuel Thibault a écrit : > It has only one NUMA node, thus triggering the code I patched over. Well, this has been working fine for a while, since that's my daily development machine and all our jenkins slaves. Can you give the usually requested details about the OS,

Re: [hwloc-devel] [hwloc-announce] Hardware locality (hwloc) v2.0.0-beta1 released

Le 20/12/2017 à 17:49, Samuel Thibault a écrit : > Samuel Thibault, on mer. 20 déc. 2017 13:57:45 +0100, wrote: >> Brice Goglin, on mar. 19 déc. 2017 11:48:39 +0100, wrote: >>> The Hardware Locality (hwloc) team is pleased to announce the first >>> beta release

[hwloc-devel] RFCs about latest API changes

/hwloc/pull/277 Make all depths *signed* ints https://github.com/open-mpi/hwloc/pull/276 Remove the "System" object type https://github.com/open-mpi/hwloc/pull/275 Move local_memory to NUMA node specific attrs https://github.com/open-mpi/hwloc/pull/274 Brice Le 26/10/2017 17

Re: [OMPI devel] HWLOC / rmaps ppr build failure

Looks like you're using a hwloc < 1.11. If you want to support this old API while using the 1.11 names, you can add this to OMPI after #include #if HWLOC_API_VERSION < 0x00010b00 #define HWLOC_OBJ_NUMANODE HWLOC_OBJ_NODE #define HWLOC_OBJ_PACKAGE HWLOC_OBJ_SOCKET #endif Brice Le 04/10/2017

Re: [hwloc-devel] C99 will be back soon

Le 27/09/2017 20:52, Brice Goglin a écrit : > Hello > > hwloc was using C99 7 years ago. We had to revert that in hwloc 1.2 > because some software embedding hwloc needed to support some non-C99 > compilers. Things have changed and C99 is well supported now. So we're > going t

Re: [hwloc-devel] Python bindings for hwloc

Hello Thanks a lot! I updated the links on the website. Note that your code should work up to 1.11.8 except for one new topology flag added in 1.11.6. I am not very good at Python but I could help finishing CUDA support if you tell me what's missing and where to look. Brice Le 02/09/2017 00:32,

Re: [OMPI devel] KNL/hwloc funny message question

Hello This message is related to /var/cache/hwloc/knl_memoryside_cache. This file exposes the KNL cluster and MCDRAM configuration, only accessible from root-only files. hwloc-dump-hwdata runs at boot time to create that file, and non-root hwloc users can read it later. Failing to read that file

Re: [hwloc-devel] [SCM] open-mpi/hwloc branch master updated. 37eb93c7dfeca1a0ce84474bac9d2f234bcbacd4

Le 29/08/2017 18:58, Samuel Thibault a écrit : > Well, for coherency only, if you prefer long command-lines there, I'm > fine with it. That's actually the difference I like between lstopo --ps and hwloc-ps. Few details but nice output for humans in the former. More details in a machine-readable

Re: [hwloc-devel] [SCM] open-mpi/hwloc branch master updated. 37eb93c7dfeca1a0ce84474bac9d2f234bcbacd4

Contrary to lstopo, hwloc-ps has no problem with long command-lines. What's the point of shortening to comm here? Brice Le 29/08/2017 18:27, 'Gitdub ' a écrit : > This is an automated email from the git hooks/post-receive script. It was > generated because a ref change was pushed to the

Re: [OMPI devel] Coverity strangeness

You can email scan-ad...@coverity.com to report bugs and/or ask what's going on. Brice Le 16/06/2017 07:12, Gilles Gouaillardet a écrit : > Ralph, > > > my 0.02 US$ > > > i noted the error message mentions 'holding lock > "pmix_mutex_t.m_lock_pthread"', but it does not explicitly mentions > >

[hwloc-devel] who's using hwloc.m4 "embedding" feature?

Hello Open MPI currently uses hwloc by "embedding" hwloc.m4 in its own configure script (instead of calling hwloc's configure script explicitly). Is there any other project doing this? Thanks Brice ___ hwloc-devel mailing list

[OMPI devel] anybody ported OMPI to hwloc 2.0 API?

Hello Did anybody start porting OMPI to the new hwloc 2.0 API (currently in hwloc git master)? Gilles, I seem to remember you were interested a while ago? I will have to do it in the near future. If anybody already started that work, please let me know. Brice

Re: [hwloc-devel] hwloc.m4: minor english fixes

FWIW, I didn't get the commit email either, and I am pretty sure it's not the first time it happens. There are no archives for this ML, do we have a way to see the logs of the emailing script that runs on github ? Brice Le 08/02/2017 16:19, Jeff Squyres (jsquyres) a écrit : > On Feb 7, 2017,

Re: [OMPI devel] hwloc missing NUMANode object

Le 05/01/2017 07:07, Gilles Gouaillardet a écrit : > Brice, > > things would be much easier if there were an HWLOC_OBJ_NODE object in > the topology. > > could you please consider backporting the relevant changes from master > into the v1.11 branch ? > > Cheers, > > Gilles Hello Unfortunately,

Re: [hwloc-devel] Git: open-mpi/hwloc annotated tag hwloc-1.11.5 deleted. hwloc-1.11.5

FWIW, I am trying to remove github automatic "release" tarballs from the github page but it actually removes the corresponding git tag. Those releases are not autogen'ed, do not contain the doc, etc. Users are confused when they download tarballs from github instead of from the hwloc website. If

Re: [hwloc-devel] [RFC] applying native OS restrictions to XML imported topology

NULL? By the way, obj->complete_{cpuset,nodeset} is also something we could drop and just have a topology->complete_{cpuset,nodeset} saying "by the way, there are others resources that we don't know much about, are offline, ...". Brice >> >> HTH >> Ralph

[hwloc-devel] [RFC] applying native OS restrictions to XML imported topology

Hello Based on recent discussion about hwloc_topology_load() being slow on some "large" platforms (almost 1 second on KNL), here's a new feature proposal: We've been recommending the use of XML to avoid multiple expensive discovery: Export to XML once at boot, and reload from XML for each actual

Re: [hwloc-devel] Query on the output of hwloc API

NUMA mode setup? > > Thanks, > Swati > > On Monday, September 26, 2016, Brice Goglin <brice.gog...@inria.fr > <mailto:brice.gog...@inria.fr>> wrote: > > Hello > > If there's no NUMA node object in your hwloc topology, it means > your machine i

Re: [hwloc-devel] Query on the output of hwloc API

Hello If there's no NUMA node object in your hwloc topology, it means your machine isn't NUMA (there's a single NUMA node), or your system doesn't report NUMA information at all (missing NUMA support in the kernel, etc). This is an old design choice that is not convenient. So we'll change that

[hwloc-devel] new distances API

Hello I just pushed a new distances API to simplify/cleanup things in hwloc 2.0. It will be merged in git master next week unless big complains. Details and comments in the pull request https://github.com/open-mpi/hwloc/pull/210 Brice ___

Re: [OMPI devel] Migration of mailman mailing lists

Yes, kill all netloc lists. Brice Le 18 juillet 2016 17:43:49 UTC+02:00, Josh Hursey a écrit : >Now that netloc has rolled into hwloc, I think it is safe to kill the >netloc lists. > >mtt-devel-core and mtt-annouce should be kept. They probably need to be >cleaned. But

Re: [OMPI devel] [PATCH] Fix for xlc-13.1.0 ICE (hwloc)

Thanks, applied to hwloc. And PR for OMPI master at https://github.com/open-mpi/ompi/pull/1657 Brice Le 06/05/2016 00:29, Paul Hargrove a écrit : > I have some good news: I have a fix!! > > FWIW: I too can build w/ xlc 12.1 (also BG/Q). > It is just the 13.1.0 on Power7 that crashes building

Re: [OMPI devel] [PATCH] Fix for xlc-13.1.0 ICE (hwloc)

Thanks I think I would be fine with that fix. Unfortunately I won't have a good internet access until sunday night. I won't be able to test anything properly earlier :/ Le 06/05/2016 00:29, Paul Hargrove a écrit : > I have some good news: I have a fix!! > > FWIW: I too can build w/ xlc 12.1

Re: [OMPI devel] [2.0.0rc2] build failure with ppc64 and "gcc -m32" (hwloc)

https://github.com/open-mpi/ompi/pull/1621 (against master, needs to go to 2.0 later) Le 03/05/2016 08:22, Brice Goglin a écrit : > Yes we should backport this to OMPI master and v2.x. > I am usually not the one doing the PR, I'd need to learn the exact > procedure first :) > > B

Re: [OMPI devel] [2.0.0rc2] build failure with ppc64 and "gcc -m32" (hwloc)

> 1.11.2, and into v2.x in particular? > Or perhaps that is Jeff's job? > > -Paul > > On Mon, May 2, 2016 at 11:04 PM, Brice Goglin <brice.gog...@inria.fr > <mailto:brice.gog...@inria.fr>> wrote: > > Should be fixed by > > https://github.com/open-mpi

Re: [OMPI devel] [2.0.0rc2] build failure with ppc64 and "gcc -m32" (hwloc)

Should be fixed by https://github.com/open-mpi/hwloc/commit/9549fd59af04dca2e2340e17f0e685f8c552d818 Thanks for the report Brice Le 02/05/2016 21:53, Paul Hargrove a écrit : > I have a linux/ppc64 host running Fedora 20. > I have configured the 2.0.0rc2 tarball with > > --prefix=[]

Re: [OMPI devel] Why is floating point number used for locality

It comes from the hwloc API. It doesn't use integers because some users want to provide their own distance matrix that was generated by benchmarks. Also we normalize the matrix to have latency 1 on the diagonal (for local memory access latency ) and that causes non-diagonal items not to be

Re: [hwloc-devel] Three patches for MSVC/ICL builds on Windows.

More comments about individual changes below. > add-ifndef-guard-around-gnu-source.patch > diff --git a/config/hwloc.m4 b/config/hwloc.m4 > index f249713..855244d 100644 > --- a/config/hwloc.m4 > +++ b/config/hwloc.m4 > @@ -486,7 +486,9 @@ EOF]) > # program_invocation_name and __progname may

Re: [hwloc-devel] Three patches for MSVC/ICL builds on Windows.

Le 05/04/2016 10:26, Samuel Thibault a écrit : > The bug here is that that HWLOC_CHECK_DECL assumed that availability > of the function was tested before, i.e. >> conftest.c(96) : fatal error C1083: Cannot open include file: 'sched.h': No >> such file or directory > was unexpected. > Adding a

Re: [hwloc-devel] Three patches for MSVC/ICL builds on Windows.

Le 04/04/2016 21:39, Peyton, Jonathan L a écrit : > > Hello everyone, > > > > I’ve been working on a build using both MSVC and the Intel Windows > compiler (ICL). These three patches allow building of hwloc + utils. > > > > 1) add-ifndef-guard-around-gnu-source.patch – this minor change only

Re: [OMPI devel] [OMPI users] configuring open mpi 10.1.2 with cuda on NVIDIA TK1

Hello hwloc doesn't have any cuda specific configure variables. We just use standard variables like LIBS and CPPFLAGS. I guess OMPI could propagate --with-cuda directories to hwloc by setting LIBS and CPPFLAGS before running hwloc m4 functions, but I don't think OMPI actually cares about hwloc

Re: [hwloc-devel] Static analysis

time), if an > app is able to survive it's nice if not then well we have to live with that. > > Thanks, > Lukas > > > -Original Message- > From: hwloc-devel [mailto:hwloc-devel-boun...@open-mpi.org] On Behalf Of > Brice Goglin > Sent: Tuesday, January 12, 2016 12:5

[hwloc-devel] new filter/ignore API

Hello I just pushed the "type-filter" branch. It's supposed to replace the old "ignore" API as well as ICACHES and IO topology flags in v2.0. Main points: * you may now enable, disable and query the "ignoring" (now called filter) for any object type * instruction caches and I/O don't need

Re: [hwloc-devel] Check the return value of getenv() in, hwloc_plugin_check_namespace

This broken code is only used when a plugin fails to find core symbols. Only happens in case of namespace issues (for instance when libhwloc is loaded by another layer of plugin, something we advice not to do). Thanks, I'll apply this. Brice Le 09/10/2015 23:04, Guy Streeter a écrit : > I am

Re: [OMPI devel] PMIX vs Solaris

Sorry, I didn't see this report before the pull request. I applied Gilles' "simple but arguable" fix to master and stable branches up to v1.9. It could be too imperfect if somebody ever changes to permissions of /devices/pci* but I guess that's not going to happen in practice. Finding the right

Re: [OMPI devel] HWLOC issue

he same cluster ... > > George. > > > On Thu, Sep 10, 2015 at 3:20 PM, Brice Goglin <brice.gog...@inria.fr > <mailto:brice.gog...@inria.fr>> wrote: > > Did it work on the same machine before? Or did OMPI enable hwloc's > PCI discovery recently? > > Does

Re: [OMPI devel] HWLOC issue

omplains with the same assert. Interestingly enough, the same > binary succeed on the other nodes of the same cluster ... > > George. > > > On Thu, Sep 10, 2015 at 3:20 PM, Brice Goglin <brice.gog...@inria.fr > <mailto:brice.gog...@inria.fr>> wrote: > > Did i

Re: [OMPI devel] HWLOC issue

Did it work on the same machine before? Or did OMPI enable hwloc's PCI discovery recently? Does lstopo complain the same? Brice Le 10/09/2015 21:10, George Bosilca a écrit : > With the current trunk version I keep getting an assert deep down in > orted. > > orted: >

Re: [OMPI devel] RFC: Remove --without-hwloc configure option

Le 04/09/2015 00:36, Gilles Gouaillardet a écrit : > Ralph, > > just to be clear, your proposal is to abort if openmpi is configured > with --without-hwloc, right ? > ( the --with-hwloc option is not removed because we want to keep the > option of using an external hwloc library ) > > if I

Re: [OMPI devel] Dual rail IB card problem

Le 01/09/2015 15:59, marcin.krotkiewski a écrit : > Dear Rolf and Brice, > > Thank you very much for your help. I have now moved the 'dubious' IB > card from Slot 1 to Slot 5. It is now reported by hwloc as bound to a > separate NUMA node. In this case OpenMPI works as could be expected: > > -

Re: [OMPI devel] Dual rail IB card problem

point number ? > > i remember i had to fix a bug in ompi a while ago > /* e.g. replace if (d1 == d2) with if((d1-d2) < epsilon) */ > > Cheers, > > Gilles > > On 9/1/2015 5:28 AM, Brice Goglin wrote: >> The locality is mlx4_0 as reported by lstopo is "near

Re: [hwloc-devel] Add support for PCIe drives

I applied a slightly different patch to v1.11 (nothing is needed in master since the discovery logic is different and more generic). thanks Brice Le 28/08/2015 21:53, Tannenbaum, Barry M a écrit : > > PCIe drives (like the Intel DC P3500/P3600/P3700) do not have a > controller – they appear

Re: [OMPI devel] Dual rail IB card problem

The locality is mlx4_0 as reported by lstopo is "near the entire machine" (while mlx4_1 is reported near NUMA node #3). I would vote for buggy PCI-NUMA affinity being reported by the BIOS. But I am not very familiar with 4x E5-4600 machines so please make sure this PCI slot is really attached to a

Re: [hwloc-devel] Add support for PCIe drives

Le 28/08/2015 21:53, Tannenbaum, Barry M a écrit : > > PCIe drives (like the Intel DC P3500/P3600/P3700) do not have a > controller – they appear directly on the PCIe bus. > > Ah nice, I needed access to a machine with such a disk before adding this support. Unfortunately, the I/O device

Re: [OMPI devel] 1.10.0rc6 - slightly different mx problem

Le 25/08/2015 05:59, Christopher Samuel a écrit : > > INRIA does have Open-MX (Myrinet Express over Generic Ethernet > Hardware), last release December 2014. No idea if it's still developed > or used.. > > http://open-mx.gforge.inria.fr/ > > Brice? > > Open-MPI is listed as working with it there.

Re: [hwloc-devel] hwloc on Windows?

rs on this project? > > > > -Barry > > > > *From:*hwloc-devel [mailto:hwloc-devel-boun...@open-mpi.org] *On > Behalf Of *Brice Goglin > *Sent:* Monday, August 17, 2015 1:36 PM > *To:* Hardware locality development list > *Subject:* Re: [hwloc-devel] hwloc o

Re: [hwloc-devel] hwloc on Windows?

0 from the download site > (http://www.open-mpi.org/software/hwloc/v1.11/). Would you prefer me > to work from the git repository? > > > > -Barry > > > > *From:*hwloc-devel [mailto:hwloc-devel-boun...@open-mpi.org] *On > Behalf Of *Brice Goglin >

Re: [hwloc-devel] hwloc on Windows?

Le 14/08/2015 23:44, Tannenbaum, Barry M a écrit : > > I’m trying to build/use hwloc on Windows. > > > > The first question is does hwloc do anything to explore the storage > devices on a Windows system? > Hello Not yet. If I remember correctly, the main issue for I/O devices on Windows is

Re: [OMPI devel] 1.8.8rc1 testing report

It was renamed from cpuid.h to cpuid-x86.h at some point. Can't check from here but the actual code should be the same in all these branches. Brice Le 31 juillet 2015 22:19:47 UTC+02:00, Ralph Castain a écrit : >Yo Paul > >1.8.8 and 1.10 do not have hwloc-1.11 in them -

Re: [hwloc-devel] hwloc-1.11 failure with pgi compiler

Le 28/07/2015 16:23, Samuel Thibault a écrit : > Brice Goglin, le Tue 28 Jul 2015 16:13:49 +0200, a écrit : >> and your commit is slightly different: (s/xchg/mov/ and removed last line). > xchg is spurious here, mov is enough. I didn't remove the last line, I > just kept the

Re: [hwloc-devel] hwloc-1.11 failure with pgi compiler

Le 28/07/2015 15:55, Samuel Thibault a écrit : > Hello, > > Paul Hargrove, le Mon 20 Jul 2015 23:12:10 -0700, a écrit : >> I believe the following inline x86 asm is correct and more robust than the >> existing code that pgi appears to reject: > Indeed, in the 32bit case, we don't need to shuffle

Re: [hwloc-devel] "make check" of 1.11 broken on x86 RedHat 8

Maybe try this. It should disable the entire BGQ backend cross-build-testing when Linux doesn't have enough pthread/cpuset support. Brice Le 21/07/2015 22:02, Paul Hargrove a écrit : > I was, at Brice's request, trying out the hwloc-1.11.0 release on all > sorts of x86 systems, with and

Re: [hwloc-devel] whelk warning

Applied a slightly better one, thanks. https://github.com/open-mpi/hwloc/commit/6376438e558f4a1541f4bb1cef18c0e86f222821 Brice Le 21/07/2015 19:07, Balaji, Pavan a écrit : > Folks, > > We see a warning about assignment from a const string to a regular string > (CFLAGS="-Wall -Werror").

Re: [hwloc-devel] hwloc-1.11 failure with pgi compiler

Thanks. Could you test this new asm on all your systems/compilers? I don't want break that fragile code again. Brice Le 21 juillet 2015 08:17:06 UTC+02:00, Paul Hargrove a écrit : >Oops - send the wrong asm code. >While "=S" is correct for the second constraint, I meant to

Re: [hwloc-devel] Possible buffer overflow in topology-linux.c

Thanks, I'll fix this. I'll try strlcpy() in case it's widely available enough. Otherwise I'll just add the ending \0 manually. Brice Le 17/07/2015 12:56, Odzioba, Lukasz a écrit : > Hi, > Static analysis detected inappropriate use of strcpy function[1] in > topology-linux.c. > There are

Re: [hwloc-devel] v1.11.0

We're basically supposed to use HWLOC_VERSION everywhere. But that requirements was added while the line below was developed in a branch at the same time. That's why it didn't get fixes. I'll review the entire tree in case there's another one missing and fix master and v1.11, thanks. Brice Le

[hwloc-devel] v1.11 coming soon

Hello I will likely release v1.11rc1 next week. The list of changes is appended below. For the record, the master branch is preparing hwloc v2.0 (which will break the API), but it's still far from ready to release. The v1.11 branch was added between v1.10 and v2.0 to release most

Re: [hwloc-devel] Using Hwloc in LLVM OpenMP

Le 18/05/2015 20:49, Peyton, Jonathan L a écrit : > > Hello Everyone, > > > > We have been developing The LLVM OpenMP runtime library project and > were hoping to incorporate the hwloc library as the primary affinity > mechanism. In order for this to happen though, > > a CMake build system

Re: [hwloc-devel] [PATCH] utils/hwloc/Makefile.am: fix install-man race condition

Le 12/05/2015 17:01, Peter Korsgaard a écrit : > > Peter Korsgaard, le Tue 12 May 2015 16:09:55 +0200, a écrit : > >> Make install contains a race condition in utils/hwloc, as both > >> install-exec-hook (through intall-exec) and install-data trigger > >> install-man: > > > I'm surprised:

Re: [hwloc-devel] [PATCH] utils/hwloc/Makefile.am: fix install-man race condition

Thanks. Unfortunately we likely have the same problem under utils/lstopo where the exec-hook needs that dependency :/ (everything was under utils/ in the past, and the dependency was duplicated when splitting into utils/lstopo and utils/hwloc) Brice Le 12/05/2015 16:09, Peter Korsgaard a écrit

Re: [hwloc-devel] Lhwloc1 duplicate symbol issue

Le 25/03/2015 21:00, Jeff Squyres (jsquyres) a écrit : > This has come up in multiple scenarios recently: when compiling OMPI (which > contains hwloc 1.9.1), you get a linker error complaining about a duplicate > symbol "Lhwloc1". > > Peter (CC'ed) was looking into this, but it came up again

Re: [OMPI devel] [OMPI users] Configuration error with external hwloc

Le 24/03/2015 20:47, Jeff Squyres (jsquyres) a écrit : > I talked to Peter off-list. > > We got a successful build going for him. > > Seems like we've identified a few issues here, though: > > 1. ./configure with gcc 4.7.2 on Debian (I didn't catch the precise version > of Debian) results in a

[hwloc-devel] hwloc v1.11 and/or v1.10.2 and v2.0

Hello I just pushed a new v1.11 branch. The idea is that master (future v2.0) won't be ready for release before several months, but it contains many changes that do not need to wait for all ABI breaks and big changes to be ready in v2.0. So I've backported these to v1.11. The summary is

Re: [hwloc-devel] [mpich-devel] Build failure in OS X, libxml required?

Le 07/03/2015 12:13, Lisandro Dalcin a écrit : > OK, I finally figured out what's going on. > > I recently upgraded to Mac OS X Yosemite, and I did not install the > Xcode command line tools. My /usr/include directory was missing, > however I had /usr/bin/clang (not sure wether it is there because

Re: [hwloc-devel] [mpich-devel] Build failure in OS X, libxml required?

Hello, Sorry but we don't add configure checks without knowing what's causing the problem. So far it only looks like a broken libxml install. We cannot check for all broken installs in the world. Otherwise one day somebody will remove printf from his libc and request a new configure check for

Re: [hwloc-devel] Coverity

Le 14/02/2015 14:44, Jeff Squyres (jsquyres) a écrit : > I added a bunch of components into the hwloc coverity setup, as well as a > dummy model file (so that coverity doesn't complain that hwloc is not fully > configured). > > Brice: do you have a nightly coverity submission script running

  1   2   3   4   5   6   7   8   >