Project

General

Profile

Task #2539

Support hwloc 2.x.x

Added by Kevin Boyd 5 months ago. Updated about 1 month ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
Difficulty:
uncategorized
Close

Description

hwloc versions 2.0.0 and up (current stable release is 2.0.1) have some API changes that need to be addressed, for example hwloc objects no longer have a memory attribute.

Associated revisions

Revision 6f58aa98 (diff)
Added by Kevin Boyd 3 months ago

Support hwloc 2.x.x

Created compatibility layer to account for API changes moving
from hwloc 1.x.x to 2.x.x while retaining support for v1.x.x.

Changes supporting hwloc 2.x.x include:
-reworked descendents lookup in topology tree to account for new
division of object children into "normal", "memory", and "io" types
-different memory access location for hwloc objects
-accessing distances (latencies) between nodes has been reworked
-different flags for accessing PCI devices
-changed numa node ancestor search to account for numa nodes no
longer being a normal part of topology tree

Fixes #2539

Change-Id: I483dda3dd344d8f7c99aa828bcc118a3d2de9dfd

History

#1 Updated by Mark Abraham 5 months ago

Yeah we should do that. We probably need to write some kind of compatibility layer because we should probably continue to support hwloc 1.x until at least GROMACS 2020.

If we bundle hwloc some time (as IMO the only practical way to support linking a fully static binary), we should definitely do so from hwloc 2.x, however.

#2 Updated by Mark Abraham 4 months ago

When he visited recently, Kevin was interested to work on providing a wrapper layer so that the current use of hwloc in gromacs doesn't need to know which version is linked. We need to be able to support both flavours of hwloc moving forward. That's currently a small surface area, so maybe we can backport to release-2018 when we see the full scope.

#3 Updated by Prashanth Kanduri 4 months ago

As mark mentioned to me, the master branch must support hwloc 1.x for at least an year before only focussing on hwloc 2.x+ only. Since the 2018 version already supports hwloc 1.x, we can consider if this is necessary on the master branch as well if 2019 plans to phase it out.

One can make two preprocessor pathways based on the hwloc version. One using the old API, and another the new one. It amounts to duplication of a few lines in hardwaretopology.cpp.

Has anyone already started work on it?

#4 Updated by Kevin Boyd 4 months ago

I'm working on it, yes.

#5 Updated by Mark Abraham 4 months ago

GROMACS 2019 will support hwloc 1.x, and (once we get this working) also hwloc 2.x. So master branch will support both flavours once we're done. We might consider removing the support for 1.x in GROMACS 2020, but that's not a decision we need to take now.

#6 Updated by Gerrit Code Review Bot 3 months ago

Gerrit received a related patchset '3' for Issue #2539.
Uploader: Kevin Boyd ()
Change-Id: gromacs~master~I483dda3dd344d8f7c99aa828bcc118a3d2de9dfd
Gerrit URL: https://gerrit.gromacs.org/8114

#7 Updated by Kevin Boyd 3 months ago

Mark Abraham wrote:

When he visited recently, Kevin was interested to work on providing a wrapper layer so that the current use of hwloc in gromacs doesn't need to know which version is linked. We need to be able to support both flavours of hwloc moving forward. That's currently a small surface area, so maybe we can backport to release-2018 when we see the full scope.

The patch on gerrit is more or less finalized. Now that we've got the scope of the patch, do you think we should backport it to release-2018? If not, we should add an error in cmake if v2 is selected.

#8 Updated by Erik Lindahl 3 months ago

I would leave the release branch alone, because every single change we make there comes with the risk of introducing another bug.

First, it will likely be quite some time before hwloc-2.0 is the default on an Linux system, and even if it is, that would just lead to the compilation failing - it can never lead to silent errors.

#9 Updated by Paul Bauer 3 months ago

I agree with Erik here, there is next to no chance of a user running into the newer version of hwloc in the time that 2018 is supported. I checked Debian as an example and there it is not even in the unstable (broken) repository.

#10 Updated by Mark Abraham 3 months ago

OK, we can fix release-2018 to only accept versions < 2.

#11 Updated by Kevin Boyd 3 months ago

  • Status changed from New to Resolved

#12 Updated by Mark Abraham about 1 month ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF