HWLOC-ANNOTATE(1)

💅 hwloc-annotate — like, the manual page, but make it make sense

okay so first things first: this is hwloc-annotate(1) from the hwloc manual, and bestie, you're gonna want to sit down for this one because she's a little loaded 🎀

---

✨ NAME ✨

hwloc-annotate — modify attributes in a XML topology 🦋

(yeah. she edits your topology files. respectfully. we love a makeover moment.)

🌸 SYNOPSIS 🌸

hwloc-annotate [options] <input.xml> <output.xml> -- <location1>
<location2> ... -- <mode> <annotation>

hwloc-annotate [options] <input.xml> <output.xml> <location> <mode>
<annotation>

so there's two whole ways to call her — the ---separated one where you can stack up multiple locations, and the plain one-liner where it's just one location and one mode and one annotation. both iconic, both valid 💖

⚠️ real talk: hwloc(7) explains the whole hwloc system and what a valid <location> even looks like. read that before this page. not me being bossy, it's literally in the original and it's important fr fr.

💅 OPTIONS 💅

• --ri — removes all the info attributes that already exist with the same name before adding the new one. only accepted in "info" mode, no exceptions. and if you omit the info value? the existing infos get replaced with nothing. poof. gone 💀
• --ci — clears the existing info attributes on the target objects before annotating. if there's no new annotation to add after clearing, set mode to none.
• --cu — clears the existing userdata from the target objects. again, if nothing else needs to happen after you clear, mode should be none.
• --cd — clears the existing distances from the topology. same deal, if nothing else after clearing, mode should be none.
• --version — reports the version and dips out. 👋
• -h, --help — displays the help message and exits. your bestie when you're lost.

🦋 DESCRIPTION 🦋

so what she does is: load a topology from a XML file, sprinkle some annotations on it, and export the resulting topology to another XML file. and yes — the input and output files may be the same file. self-care, she contains multitudes 🫶

the annotation can be string info attributes. this is all specified by the mode:

info <name> <value>

specifies a new string info attribute whose name is name and value is value. simple. clean. ate. ✨

subtype <subtype>

says the subtype attribute of the object should now be subtype. and if you give her an empty string, the subtype is removed. we love a deletion arc 💅

size <size>

specifies the size of a cache or NUMA node. the value may be suffixed with kB, KiB, MB, MiB, GB, GiB, etc. pls use your units, she's not a mind reader 🎀

misc <name>

specifies a new Misc object name. cute little guy, no notes.

memattr <name> <flags>

registers a new memory attribute whose name is name and flags is flags. location is ignored in this mode, she literally does not care where you point her here 🙈

flags may be given as numeric values or as a comma-separated list of flag names that are passed to hwloc_memattr_register(). those names may be substrings of actual flag names as long as a single one matches. for instance, a value of 1 (or higher) means that highest values are considered best for this attribute. slay.

memattr <name> <initiator> <value>

set the memory attribute (name is name) from initiator initiator (either an object or a CPU-set) to target NUMA node location to value value. very "from here to there with this number" energy 💜

if this attribute doesn't require specific initiators, initiator is ignored. no hard feelings.

standard attribute names are Capacity, Locality, Bandwidth, and Latency. and all existing attributes in the input topology may be listed with:

$ lstopo --memattrs -i input.xml

cpukind <cpuset> <efficiency> <flags> [<infoname> <infovalue>]

specifies the kind of CPU for PUs listed in the given cpuset. location is ignored in this mode (she said what she said 💅).

efficiency is an abstracted efficiency value that will enforce ranking of kinds. it should be -1 if unknown. (unknown is a valid vibe, just be honest about it.)

flags must be 0 for now. that's the whole rule. zero. that's it.

if infoname and infovalue are given and non-empty, they're added as info attributes to this kind of CPU. 🎀

see the function hwloc_cpukinds_register() for details.

distances <filename> [<flags>]

specifies new distances to be added to the topology using specifications in <filename>. the optional flags (0 unless specified) corresponds to the flags given to the function hwloc_distances_set(). location is ignored in this mode.

okay the file format, pay attention bestie:

• the real first line of the pointed file must be a integer representing a distances kind as defined in hwloc/distances.h
• the second line is the number of objects involved in the distances
• the next lines contain one object each
• the next lines contain one distance value each, or a single line may be given with a integer combination of format x*y or x*y*z
• an optional line before all others may start with name= to specify the name of the distances structure if any

that's the whole recipe, no cap 🍓

distances-transform <name> links

transform a bandwidth distances structure named <name> into links. see the documentation of HWLOC_DISTANCES_TRANSFORM_LINKS in hwloc/distances.h for details. 🔥

distances-transform <name> merge-switch-ports

when switches appear in the matrix as different ports, merge all of them into a single port for clarity. this currently only applies to the NVLinkBandwidth matrix between NVIDIA GPUs. see the documentation of HWLOC_DISTANCES_TRANSFORM_MERGE_SWITCH_PORTS in hwloc/distances.h for details.

distances-transform <name> transitive-closure

if objects are connected across a switch, apply a transitive-closure to report the bandwidth through that switch. this currently only applies to the NVLinkBandwidth matrix between NVIDIA GPUs. the bandwidth between all pairs of GPUs will be exposed instead of bandwidths between single GPUs and single NVSwitch ports. see the documentation of HWLOC_DISTANCES_TRANSFORM_TRANSITIVE_CLOSURE in hwloc/distances.h for details. 🌈

distances-transform <name> remove-obj <obj>

remove the given object from the distances structure named <name>. bye bitch (affectionate) 👋💖

distances-transform <name> replace-objs <oldtype> <newtype>

replace objects of type <oldtype> in distances structure named <name> with objects of type <newtype> with same locality. if <oldtype> or <newtype> are not object types, they're assumed subtypes of OS devices, e.g. "NVML" or "OpenCL". see the documentation of hwloc_get_obj_with_same_locality() in hwloc/helper.h for details.

and if <newtype> is "NULL", objects are removed from the distances structure. gone. deleted. blocked. 💀

none

no new annotation is added. this is useful when clearing existing attributes. she's just here to hold your purse while you clean up 🫶

---

so — annotations may be added to one specific object in the topology, all of them, or all of a given type. this is specified by the location (see also EXAMPLES below, they're good ones). multiple locations may be affected if they're specified between --. objects may be specified as location tuples, as explained in hwloc(7). however — hexadecimal bitmasks are not accepted, since they may correspond to multiple objects. she said no ❌

NOTE: the existing annotations may be listed with hwloc-info. 👑

NOTE: it is highly recommended that you read the hwloc(7) overview page before reading this man page. most of the concepts described in hwloc(7) directly apply to the hwloc-annotate utility. seriously bestie, go read it, i'll wait 💜

🎀 EXAMPLES 🎀

hwloc-annotate's operation is best described through several examples. so let's go, group chat, show and tell time ✨

add an info attribute to all Core and PU objects:

$ hwloc-annotate input.xml output.xml -- Core:all PU:all -- info infoname infovalue

only add to all Core objects:

$ hwloc-annotate input.xml output.xml Core:all info infoname infovalue

add an info attribute to OS device #2 and #3:

$ hwloc-annotate input.xml output.xml os:2-3 info infoname infovalue

change package objects to green with red text in the lstopo graphical output:

$ hwloc-annotate topo.xml topo.xml package:all info lstopoStyle "Background=#00ff00;Text=#ff0000"
$ lstopo -i topo.xml

add a Misc object named "foobar" under the root object of the topology and modify the input XML directly:

$ hwloc-annotate file.xml file.xml root misc foobar

🔥 Examples with memory attributes

set the memory attribute latency to 123 nanoseconds from the PUs in the first package to the first NUMA node:

$ hwloc-annotate topo.xml topo.xml numanode:0 memattr Latency $(hwloc-calc package:0) 123

register a memory attribute MyApplicationPerformance (with flags specifying that it requires an initiator and reports higher values first) and set its value for initiator CPU-set 0x11 to NUMA node #2 to 2345:

$ hwloc-annotate topo.xml topo.xml ignored memattr MyApplicationPerformance need_init,higher
$ hwloc-annotate topo.xml topo.xml numanode:2 memattr MyApplicationPerformance 0x11 2345

to clarify that NUMA node #0 is DDR while NUMA node #1 is HBM:

$ hwloc-annotate topo.xml topo.xml numa:0 subtype DDR
$ hwloc-annotate topo.xml topo.xml numa:1 subtype HBM

🌸 Examples with CPU kinds

specify that PU 0-3 and PU 4-7 are of different kinds, and the latter is more efficient:

$ hwloc-annotate topo.xml topo.xml dummy cpukind 0x0f 0 0 CoreType Small
$ hwloc-annotate topo.xml topo.xml dummy cpukind 0xf0 1 0 CoreType Big

(see, dummy because location is ignored. she's not even pretending to look 💅)

🦋 Examples with distances matrices

replace NUMA nodes with Packages in the NUMALatency distances matrix, when they have the exact same locality:

$ hwloc-annotate topo.xml topo.xml -- dummy -- distances-transform NUMALatency replace-objs numanode packages

remove NUMA node #3 from the NUMALatency distances matrix:

$ hwloc-annotate topo.xml topo.xml -- dummy -- distances-transform NUMALatency remove-obj numa:3

merge all NVSwitch ports bandwidth information into a single port in the NVLinkBandwidth matrix:

$ hwloc-annotate topo.xml topo.xml -- dummy -- distances-transform NVLinkBandwidth merge-switch-ports

apply a transitive closure to get inter-GPU bandwidth across NVSwitches in the NVLinkBandwidth matrix:

$ hwloc-annotate topo.xml topo.xml -- dummy -- distances-transform NVLinkBandwidth transitive-closure

⭐ RETURN VALUE ⭐

upon successful execution, hwloc-annotate generates the output topology. the return value is 0. she did it, she slayed, everyone clapped 👏

hwloc-annotate will return nonzero if any kind of error occurs, such as (but not limited to) failure to parse the command line. yeah. that happens. 😭

👑 SEE ALSO 👑

hwloc(7), lstopo(1), hwloc-info(1)

go read those too, they're the friend group 💖

---

and that's the whole page, bestie!! this was 2.15.0, dated Sep 23, 2026, brought to you by the hwloc girlies. mwah 💋✨