The Hardware Locality (hwloc) team is pleased to announce the first
release candidate for v1.11.0:

   http://www.open-mpi.org/projects/hwloc/

v1.11.0rc1 is the first milestone of a major feature release.
It brings support for the upcoming "Knights Landing" Xeon Phi,
more information about memory and storage devices on Linux,
as well as many small improvements everywhere.

By the way, there is now a best of lstopo at
   http://www.open-mpi.org/projects/hwloc/lstopo/

Version 1.11.0
--------------
* API
  + Socket objects are renamed into Package to align with the terminology
    used by processor vendors. The old HWLOC_OBJ_SOCKET type and "Socket"
    name are still supported for backward compatibility.
  + HWLOC_OBJ_NODE is replaced with HWLOC_OBJ_NUMANODE for clarification.
    HWLOC_OBJ_NODE is still supported for backward compatibility.
    "Node" and "NUMANode" strings are supported as in earlier releases.
* Detection improvements
  + Add support for Intel Knights Landing Xeon Phi.
    Thanks to Grzegorz Andrejczuk and Lukasz Anaczkowski.
  + Add Vendor, Model, Revision, SerialNumber, Type and LinuxDeviceID
    info attributes to Block OS devices on Linux. Thanks to Vineet Pedaballe
    for the help.
    - Add --disable-libudev to avoid dependency on the libudev library.
  + Add "MemoryDevice" Misc objects with information about DIMMs, on Linux
    when privileged and when I/O is enabled.
    Thanks to Vineet Pedaballe for the help.
  + Add a PCISlot attribute to PCI devices on Linux when supported to
    identify the physical PCI slot where the board is plugged.
  + Add CPUStepping info attribute on x86 processors,
    thanks to Thomas Röhl for the suggestion.
  + Ignore the device-tree on non-Power architectures to avoid buggy
    detection on ARM. Thanks to Orion Poplawski for reporting the issue.
  + Work-around buggy Xeon E5v3 BIOS reporting invalid PCI-NUMA affinity
    for the PCI links on the second processor.
  + Add support for CUDA compute capability 5.x, thanks Benjamin Worpitz.
  + Many fixes to the x86 backend
    - Add L1i and fix L2/L3 type on old AMD processors without topoext support.
    - Fix Intel CPU family and model numbers when basic family isn't 6 or 15.
    - Fix package IDs on recent AMD processors.
    - Fix misc issues due to incomplete APIC IDs on x2APIC processors.
    - Avoid buggy discovery on old SGI Altix UVs with non-unique APIC IDs.
  + Gather total machine memory on NetBSD.
* Tools
  + lstopo
    - Collapse identical PCI devices unless --no-collapse is given.
      This avoids gigantic outputs when a PCI device contains dozens of
      identical virtual functions.
    - The ASCII art output is now called "ascii", for instance in
      "lstopo -.ascii".
      The former "txt" extension is retained for backward compatibility.
    - Automatically scales graphical box width to the inner text in Cairo,
      ASCII and Windows outputs.
    - Add --rect to lstopo to force rectangular layout even for NUMA nodes.
    - Objects may have a Type info attribute to specific a better type name
      and display it in lstopo.
  + hwloc-annotate
    - May now operate on all types of objects, including I/O.
    - May now insert Misc objects in the topology.
    - Do not drop instruction caches and I/O devices from the output anymore.
  + Fix lstopo path in hwloc-gather-topology after install.
* Misc
  + Fix PCI Bridge-specific depth attribute.
  + Fix hwloc_bitmap_intersect() for two infinite bitmaps.
  + Improve the performance of object insertion by cpuset for large
    topologies.
  + Prefix verbose XML import errors with the source name.
  + Improve pkg-config checks and error messages.
  + Fix excluding after a component with an argument in the HWLOC_COMPONENTS
    environment variable.
  + Fix the recommended way in documentation and examples to allocate memory
    on some node, it should use HWLOC_MEMBIND_BIND.
    Thanks to Nicolas Bouzat for reporting the issue.
  + Add a "Miscellaneous objects" section in the documentation.
  + Add a FAQ entry "What happens to my topology if I disable symmetric
    multithreading, hyper-threading, etc. ?" to the documentation.

--
Brice

Reply via email to