HWLOC-INFO(1)

okay so this is hwloc-info(1) from the hwloc manual, and it's giving main character energy for your topology πŸ’…. Like, it shows some information about some objects, a topology, or supported featuresβ€”and yes, she ate ✨.

✨ NAME ✨

hwloc-info β€” shows some information about some objects, a topology, or supported features. That's the whole vibe: you ask, she spills πŸ’–.

🌸 SYNOPSIS 🌸

the synopsis is lowkey two moods:

hwloc-info [ options ]...  <object>...
hwloc-info [ options ] root
hwloc-info [ options ] [ topology | levels | support ]

<object>... may be a space-separated list of target objects to query. The program reports all information about one object before looking at the next one:

$ hwloc-info core:2 package:1 pu:all
Core L#2
 type = Core
 ...
Package L#1
 ...
PU L#0
 ...
PU L#1
 ...

The list may also contain special keywords such as:

  • root for the topology root object.
  • levels for information about topology levels (default if no target object is given, identical to --topology).
  • topology for topology info attributes stored in the root object (for forward compatibility with topology info attrs in hwloc 3.0), as well as the number of levels (depth), PUs, NUMANodes, and CPU kinds.
  • support for information about supported features (identical to --support).

Real targets and special keywords may be combined:

$ hwloc-info core:2 topology pu:3 levels

Note that hwloc(7) provides a detailed explanation of the hwloc system and of valid <object> formats; it should be read before reading this man page, fr fr 🫢.

πŸ’… OPTIONS πŸ’…

okay bestie, here's the option buffetβ€”every flag, every value, no skips πŸ“

  • --objects β€” reports information about specific objects. This is the default if some objects are given on the command-line. iykyk πŸ’…
  • --topology β€” reports a summary of the topology instead of info about some specific objects. This is equivalent to passing levels as a target object on the command-line. This is the default if no object is given on the command-line. slay ✨
  • --support β€” reports the features that are supported by hwloc on the topology. Those features are the ones available through the hwloc_topology_get_support() function. This is useful for verifying which CPU or memory binding options are supported by the current hwloc installation. This is equivalent to passing support as a target object on the command-line. 🫢
  • -i <path>, --input <path> β€” reads the topology from <path> instead of discovering the topology of the local machine. If <path> is a file, it may be an XML file exported by a previous hwloc program. If <path> is "-", standard input may be used as an XML file. On Linux, <path> may be a directory containing the topology files gathered from another machine topology with hwloc-gather-topology. On x86, <path> may be a directory containing a cpuid dump gathered with hwloc-gather-cpuid. When the archivemount program is available, <path> may also be a tarball containing such Linux or x86 topology filesβ€”but note that this mode may be slow for large tarballs. 🐒
  • -i <specification>, --input <specification> β€” simulates a fake hierarchy instead of discovering the topology on the local machine. If <specification> is "node:2 pu:3", the topology will contain two NUMA nodes with 3 processing units in each of them. The <specification> string must end with a number of PUs. no cap 🧚
  • --if <format>, --input-format <format> β€” enforces the input in the given format, among xml, fsroot, cpuid and synthetic. periodt πŸ’…
  • -v, --verbose β€” includes additional detail. πŸ‘€
  • -q, --quiet, -s, --silent β€” reduces the amount of details to show. A single summary line per object is displayed. short n sweet πŸ“
  • --get-attr <name> β€” only reports the attribute of name <name> for each object instead of all attributes. The name must exactly match what is usually reported by the program, for instance "complete cpuset" in "0.1: complete cpuset = %0x00ffff00". Only the value is reported; any other prefix or object name is ignored, so the output may easily be used by other tools. This option also works on topology information, but it is ignored for levels and support keywords. πŸ”₯
  • --ancestors β€” displays information about the object as well as about all its ancestors up to the root of the topology. This is identical to --ancestor all. πŸ‘‘
  • --ancestor <type> β€” only displays the object ancestors that match the given type. Some special values matching multiple types may also be given: kind=normal (CPU objects, including caches), kind=cpu (CPU objects, excluding caches), kind=cache (all caches, including memory-side caches), kind=memory (NUMA nodes or memory-side caches), kind=io (IO objects), kind=all (all objects). See also Object Kind in Terms and Definitions in the documentation. The prefix kind= may be omitted if there is no ambiguity. If multiple ancestors match, they are reported from the deepest to the highest in the topology. Adding --first will only show the first one. πŸ’œ
  • --children β€” displays information about the object children. tiny topology gremlins but make it cute 🌱
  • --descendants <type> β€” displays information about the object descendants that match the given type. Some special values matching multiple types may also be given: kind=normal (CPU objects, including caches), kind=cpu (CPU objects, excluding caches), kind=cache (all caches, including memory-side caches), kind=memory (NUMA nodes or memory-side caches), kind=io (IO objects), kind=all (all objects). See also Object Kind in Terms and Definitions in the documentation. The prefix kind= may be omitted if there is no ambiguity. If multiple objects match, they are reported in a depth-first order (first child, then its children, etc., then second child, etc.). Adding --first will only show the first one. 🌈
  • --local-memory β€” displays information about the NUMA nodes that are local to the given object. local girlie vibes πŸŽ€
  • --local-memory-flags β€” changes the flags used to select local NUMA nodes. Flags may be given as numeric values or as a comma-separated list of flag names that are passed to hwloc_get_local_numanode_objs(). Those names may be substrings of actual flag names as long as a single one matches. The default is 3 (or smaller,larger), which means NUMA nodes are displayed if their locality either contains or is contained in the locality of the given object. This option enables --local-memory. πŸ¦‹
  • --best-memattr <name> β€” enables the listing of local memory nodes with --local-memory, but only displays the local nodes that have the best value for the memory attribute given by <name> (or as an index). If the memory attribute values depend on the initiator, the object given to hwloc-info is used as the initiator. <name> may be suffixed with flags to tune the selection of best nodes, for instance as bandwidth,strict,default. default means that default nodes are reported if no best could be found (see --default-nodes). If neither best nor default nodes could be found, all local nodes are reported. strict means that nodes are selected only if their performance is the best for all the input CPUs. On a dual-socket machine with HBM in each socket, both HBMs are the best for their local socket, but not for the remote socket. Hence both HBM are also considered best for the entire machine by default, but none if strict. πŸ’€
  • --default-nodes β€” displays information about the default NUMA nodes that are local to the given object. This usually includes DRAM memory nodes (or nodes of the same memory tier) rather than nodes with specific characteristics (HBM, NVM, CXL, etc). See hwloc_topology_get_default_nodeset() for details. 🌸
  • --first β€” for each input object, only reports the first matching output object (first ancestor, first child, etc.). one and done ✨
  • -n β€” when outputting object information, prefixes each line with the index of the considered object within the input. For instance, if three cores were given in input, the output lines will be prefixed with "0: ", "1: " or "2: ". If --ancestor is also used, the prefix will be "X.Y: " where X is the index of the considered object within the input, and Y is the parent index (0 for the object itself, increasing towards the root of the topology). πŸ’…
  • --disallowed β€” includes objects disallowed by administrative limitations. rebel girlie behavior but make it sysadmin 🫢
  • --restrict <cpuset> β€” restricts the topology to the given cpuset. This removes some PUs and their now-child-less parents. Beware: restricting the PUs in a topology may change the logical indexes of many objects, including NUMA nodes. ⚠️
  • --restrict nodeset=<nodeset> β€” restricts the topology to the given nodeset (unless --restrict-flags specifies something different). This removes some NUMA nodes and their now-child-less parents. Beware: restricting the NUMA nodes in a topology may change the logical indexes of many objects, including PUs. ⚠️
  • --restrict binding β€” restricts the topology to the current process binding. This option requires the use of the actual current machine topology (or any other topology with --thissystem or with HWLOC_THISSYSTEM set to 1 in the environment). Beware: restricting the topology may change the logical indexes of many objects, including PUs and NUMA nodes. ⚠️
  • --restrict-flags <flags> β€” enforces flags when restricting the topology. Flags may be given as numeric values or as a comma-separated list of flag names that are passed to hwloc_topology_restrict(). Those names may be substrings of actual flag names as long as a single one matches, for instance bynodeset,memless. The default is 0 (or none). πŸŽ€
  • --filter <type>:<kind>, --filter <type> β€” filters objects of type <type>, or of any type if <type> is "all". "io", "cache" and "icache" are also supported. <kind> specifies the filtering behavior. If "none" or not specified, all objects of the given type are removed. If "all", all objects are kept as usual. If "structure", objects are kept when they bring structure to the topology. If "important" (only applicable to I/O and Misc), only important objects are kept. See hwloc_topology_set_type_filter() for more details. πŸ”₯
  • --no-icaches β€” Instruction caches? Not invited πŸ’… Only Data and Unified caches get to show up. Literally the same thing as --filter icache:none.
  • --no-io β€” Hides every I/O device and bridge, no exceptions. Identical to --filter io:none. Just so you know, the default vibe is showing common devices (GPUs, NICs, block devices, ...) plus the interesting bridges β€” so this is you saying "not today" to all of that.
  • --no-bridges β€” Nukes all I/O bridges except hostbridges. Identical to --filter bridge:none. Again, default behavior = common devices (GPUs, NICs, block devices, ...) and interesting bridges are shown, bestie.
  • --whole-io β€” Now THIS is main character energy πŸ‘‘ Show all the I/O devices and bridges. Identical to --filter io:all. (Default is only common devices (GPUs, NICs, block devices, ...) and interesting bridges, so this is the "give me everything" option.)
  • --thissystem β€” Tells hwloc to assume the backend you picked provides the topology of the system we're actually running on. Super useful when you're using --restrict binding and loading a custom topology, like an XML file. 🫢
  • --pid <pid> β€” Detects the topology as seen by process <pid>, like... as if process <pid> did the discovery itself, periodt. Heads up: this can, for instance, change the set of allowed processors. It'll also show that process's current CPU binding by marking the corresponding PUs (in Green in the graphical output β€” peep the COLORS section below β€” or by appending (binding) to the verbose text output). And if you pass 0 as the pid, you get the current binding for the lstopo process. πŸ’€
  • -p, --physical β€” Uses OS/physical indexes instead of logical indexes for input.
  • -l, --logical β€” Uses logical indexes instead of physical/OS indexes for input (this is the default, so, yeah).
  • --version β€” Reports the version and dips out. ✨
  • -h, --help β€” Displays the help message and exits. Classic.

🌸 DESCRIPTION 🌸

hwloc-info displays information about the specified objects. It's built to be used with tools such as grep for filtering certain attribute lines β€” yes, they planned the pipeline life for you, iykyk. πŸŽ€

When no object is specified, or when --topology is passed, hwloc-info prints a summary of the topology. And when --support is passed, it lists the supported features for the topology. Obsessed with the range honestly.

Objects may be specified as location tuples, as explained in hwloc(7). But β€” hexadecimal bitmasks are not accepted, because they may correspond to multiple objects. Not me gatekeeping, it's just how it is πŸ™ˆ

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-calc utility. Fr fr, go read it first bestie, it'll make everything click. πŸ’–

πŸ¦‹ EXAMPLES πŸ¦‹

Wanna see info about each package? Say less:

$ hwloc-info package:all
Package L#0
 logical index = 0
...

Curious about the core whose physical index is 2? Run this:

$ hwloc-info -p core:2
Core L#1
 logical index = 1
 os index = 2
...

Listing the OS devices that are of subtype OpenCL:

$ hwloc-info -s "os[OpenCL]:all"
CoProc:6
CoProc:8

Finding the PCI bus ID of PCI devices containing OpenCL devices β€” this one ate πŸ”₯:

$ hwloc-info --ancestor PCI --get-attr "attr PCI bus id"
'os[opencl]:all'
 0000:05:00.0
 0000:42:00.0

Listing the NUMA nodes that are local to a PU:

$ hwloc-info --local-memory pu:25
NUMANode L#6 = local memory #0 of PU L#25
 type = NUMANode
...
NUMANode L#7 = local memory #1 of PU L#25
 type = NUMANode
...

Showing the best-bandwidth node(s) among NUMA nodes local to a PU β€” literal bestie behavior 🫢:

$ hwloc-info --local-memory --best-memattr bandwidth pu:25
NUMANode L#7 = local memory #1 of PU L#25
 type = NUMANode
...

Finding where a NUMA node is attached in the hierarchy of CPU cores (lowercase "to find" in the original, keeping that energy ✨):

$ hwloc-info --ancestor kind=normal --first -s numa:1
Package:0

Want to see levels and topology info attributes stored in the root object? Here ya go:

$ hwloc-info levels topology
depth 0:           1 Machine (type #0)
 depth 1:          1 Package (type #1)
  depth 2:         2 Core (type #2)
   depth 3:        4 PU (type #3)
Special depth -3:  1 NUMANode (type #13)
info Backend = Linux
info LinuxCgroup = /user/622
info Architecture = x86_64
info hwlocVersion = 3.0.0a1-git

πŸ’œ SEE ALSO πŸ’œ

hwloc(7), lstopo(1), hwloc-calc(1), hwloc-bind(1), hwloc-ps(1) β€” go read the whole friend group, they all slay in their own way 🌈


okay that's the whole page babes, you're officially a hwloc-info scholar πŸŽ“βœ¨

This one's from 2.15.0, dated Sep 23, 2026 β€” the HWLOC-INFO(1) girlies stay winning πŸ‘‘πŸ’… mwah, go touch some topology πŸ’–

πŸ“¦ where this page comes from
  • arch rolling: hwloc 2.15.0-1 Β· BSD-3-Clause
  • πŸ“œ the page's license: BSD-3-Clause
  • πŸ’– girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms