clean up packages

This commit is contained in:
ton
2023-04-02 11:10:39 +07:00
parent 3220a173bc
commit 43c3070fce
3184 changed files with 2806 additions and 61772 deletions
@@ -1,563 +0,0 @@
#
# Copyright © 2018-2022 Inria. All rights reserved.
# See COPYING in top-level directory.
#
# This file is also compatible with zsh (once bashcompinit is enabled)
# bash < 4 doesn't support compopt
[[ -z "$ZSH_VERSION" ]] && [[ "${BASH_VERSINFO[0]:-0}" -lt 4 ]] && return
# TODO only disable the nospace completion of "--filter"
_lstopo() {
local INPUT_FORMAT=(xml synthetic fsroot cpuid)
local OUTPUT_FORMAT=(default window console ascii tikz tex fig pdf nativesvg cairosvg ps png svg xml shmem synthetic)
local TYPES=("Machine" "Misc" "Group" "NUMANode" "MemCache" "Package" "Die" "L1" "L2" "L3" "L4" "L5" "L1i" "L2i" "L3i" "Core" "Bridge" "PCIDev" "OSDev" "PU")
local FILTERKINDS=("none" "all" "structure" "important")
local OPTIONS=(-l --logical
-p --physical
--logical-index-prefix
--os-index-prefix
--output-format --of
-f --force
--only
-v --verbose
-s --silent
--distances
--distances-transform
--memattrs
--cpukinds
--windows-processor-groups
-c --cpuset
-C --cpuset-only
--taskset
--filter --ignore
--no-caches
--no-useless-caches
--no-icaches
--merge
--no-collapse
--factorize --factorize=
--no-factorize --no-factorize=
--restrict
--restrict-flags
--no-io
--no-bridges
--whole-io
--input -i
--input-format --if
--no-smt
--thissystem
--pid
--disallowed --whole-system
--allow
--flags
--children-order
--no-cpukinds
--fontsize
--gridsize
--linespacing
--thickness
--horiz --horiz=
--vert --vert=
--rect --rect=
--text --text=
--no-text --no-text=
--index --index=
--no-index --no-index=
--attrs --attrs=
--no-attrs --no-attrs=
--no-legend
--no-default-legend
--append-legend
--grey --greyscale
--palette
--binding-color
--disallowed-color
--top-color
--export-xml-flags
--export-synthetic-flags
--ps --top
--version
-h --help
)
local cur=${COMP_WORDS[COMP_CWORD]}
local prev=${COMP_WORDS[COMP_CWORD-1]}
if [[ $COMP_CWORD == 1 || $cur == -* ]] ; then
COMPREPLY=( `compgen -W "${OPTIONS[*]}" -- "$cur"` )
elif [[ $COMP_CWORD -ge 3 && "${COMP_WORDS[COMP_CWORD-2]}" == "--filter" && "$cur" == ":" ]] ; then
COMPREPLY=( `compgen -W "${FILTERKINDS[*]}"` )
elif [[ $COMP_CWORD -ge 4 && "${COMP_WORDS[COMP_CWORD-3]}" == "--filter" && "$prev" == ":" ]] ; then
COMPREPLY=( `compgen -W "${FILTERKINDS[*]}" -- "$cur"` )
elif [[ "$cur" == "=" && " --horiz --vert --rect --text --no-text --index --no-index --attrs --no-attrs --no-factorize " =~ " $prev " ]] ; then
COMPREPLY=( `compgen -W "${TYPES[*]}"` )
# we could also support "<type1>,<type2>,..." for --index/attrs/text but "," is not a completion word separator
elif [[ $COMP_CWORD -ge 3 && "$prev" == "=" && " --horiz --vert --rect --text --no-text --index --no-index --attrs --no-attrs --no-factorize --factorize " =~ " ${COMP_WORDS[COMP_CWORD-2]} " ]] ; then
COMPREPLY=( `compgen -W "${TYPES[*]}" -- "$cur"` )
elif [[ "$cur" == "=" && "--factorize" = "$prev" ]] ; then
COMPREPLY=( `compgen -W "${TYPES[*]}"` "<N>" "<N,F,L>" )
else
case "$prev" in
--of | --output-format)
COMPREPLY=( `compgen -W "${OUTPUT_FORMAT[*]}" -- "$cur"` )
;;
--only | --ignore)
COMPREPLY=( `compgen -W "${TYPES[*]}" -- "$cur"` )
;;
--filter)
COMPREPLY=( `compgen -W "${TYPES[*]/%/:} cache: icache: io:" -- "$cur"` ) && compopt -o nospace
;;
--restrict)
COMPREPLY=( `compgen -W "binding <cpuset>" -- "$cur"` )
;;
--logical-index-prefix | --os-index-prefix)
COMPREPLY=( "<string>" "" )
;;
-i | --input)
_filedir xml
;;
--if | --input-format)
COMPREPLY=( `compgen -W "${INPUT_FORMAT[*]}" -- "$cur"` )
;;
--pid)
COMPREPLY=( "<pid>" "" )
;;
--allow)
COMPREPLY=( `compgen -W "all local <mask> nodeset=<mask>" -- "$cur"` )
;;
--restrict-flags | --export-xml-flags | --export-synthetic-flags | --fontsize | --gridsize | --linespacing | --thickness)
COMPREPLY=( "<integer>" "" )
;;
--append-legend)
COMPREPLY=( "<line of text>" "" )
;;
--palette)
COMPREPLY=( `compgen -W "grey" "greyscale" "default" "colors" "white" "none" -- "$cur"` )
;;
--binding-color | --disallowed-color | --top-color)
COMPREPLY=( `compgen -W "none <#rrggbb>" -- "$cur"` )
;;
--children-order)
COMPREPLY=( `compgen -W "plain memoryabove" -- "$cur"` )
;;
--distances-transform)
COMPREPLY=( `compgen -W "links merge-switch-ports transitive-closure" -- "$cur"` )
;;
esac
fi
}
complete -F _lstopo lstopo
complete -F _lstopo lstopo-no-graphics
complete -F _lstopo hwloc-ls
_hwloc_info(){
local TYPES=("Machine" "Misc" "Group" "NUMANode" "MemCache" "Package" "Die" "L1" "L2" "L3" "L4" "L5" "L1i" "L2i" "L3i" "Core" "Bridge" "PCIDev" "OSDev" "PU")
local FILTERKINDS=("none" "all" "structure" "important")
local OPTIONS=(--objects
--topology
--support
-v --verbose
-s --silent
--ancestors
--ancestor
--children
--descendants
--local-memory
--local-memory-flags
--best-memattr
-n
--restrict
--restrict-flags
--filter
--no-icaches
--no-io
--no-bridges
--whole-io
--input -i
--input-format --if
--thissystem
--pid
--disallowed --whole-system
-l --logical
-p --physical
--version
-h --help
)
local cur=${COMP_WORDS[COMP_CWORD]}
local prev=${COMP_WORDS[COMP_CWORD-1]}
if [[ $COMP_CWORD == 1 || $cur == -* ]] ; then
COMPREPLY=( `compgen -W "${OPTIONS[*]}" -- "$cur"` )
elif [[ $COMP_CWORD -ge 3 && "${COMP_WORDS[COMP_CWORD-2]}" == "--filter" && "$cur" == ":" ]] ; then
COMPREPLY=( `compgen -W "${FILTERKINDS[*]}"` )
elif [[ $COMP_CWORD -ge 4 && "${COMP_WORDS[COMP_CWORD-3]}" == "--filter" && "$prev" == ":" ]] ; then
COMPREPLY=( `compgen -W "${FILTERKINDS[*]}" -- "$cur"` )
else
case "$prev" in
--restrict)
COMPREPLY=( `compgen -W "binding <cpuset>" -- "$cur"` )
;;
--restrict-flags)
COMPREPLY=( "<integer>" "" )
;;
-i | --input)
_filedir xml
;;
--if | --input-format)
COMPREPLY=( `compgen -W "${INPUT_FORMAT[*]}" -- "$cur"` )
;;
--pid)
COMPREPLY=( "<pid>" "" )
;;
--filter)
COMPREPLY=( `compgen -W "${TYPES[*]/%/:} cache: icache: io:" -- "$cur"` ) && compopt -o nospace
;;
--ancestor | --descendants)
COMPREPLY=( `compgen -W "${TYPES[*]}" -- "$cur"` )
;;
--local-memory-flags)
COMPREPLY=( "<flags>" "" )
;;
--best-memattr)
COMPREPLY=( "<memattr>" "" )
;;
esac
fi
}
complete -F _hwloc_info hwloc-info
_hwloc_bind(){
local OPTIONS=(--cpubind
--membind
--mempolicy
--best-memattr
--logical -l
--physical -p
--single
--strict
--get
-e --get-last-cpu-location
--nodeset
--pid
--tid
--taskset
--restrict
--restrict-flags
--disallowed --whole-system
--hbm
--no-hbm
--no-smt --no-smt=N
-f --force
-q --quiet
-v --verbose
--version
-h --help
)
local cur=${COMP_WORDS[COMP_CWORD]}
local prev=${COMP_WORDS[COMP_CWORD-1]}
if [[ $COMP_CWORD == 1 || $cur == -* ]] ; then
COMPREPLY=( `compgen -W "${OPTIONS[*]}" -- "$cur"` )
else
case "$prev" in
--mempolicy)
COMPREPLY=( `compgen -W "default firsttouch bind interleave nexttouch" -- "$cur"` )
;;
--pid)
COMPREPLY=( "<pid>" "" )
;;
--tid)
COMPREPLY=( "<tid>" "" )
;;
--restrict)
COMPREPLY=( "<bitmask>" "" )
;;
--restrict-flags)
COMPREPLY=( "<integer>" "" )
;;
--best-memattr)
COMPREPLY=( "<memattr>" "" )
;;
esac
fi
}
complete -F _hwloc_bind hwloc-bind
_hwloc_calc(){
local TYPES=("Machine" "Misc" "Group" "NUMANode" "MemCache" "Package" "Die" "L1" "L2" "L3" "L4" "L5" "L1i" "L2i" "L3i" "Core" "Bridge" "PCIDev" "OSDev" "PU")
local OPTIONS=(-N --number-of
-I --intersect
-H --hierarchical
--largest
--local-memory
--local-memory-flags
--best-memattr
-l --logical
-p --physical
--li --logical-input
--lo --logical-output
--pi --physical-input
--po --physical-output
-n --nodeset
--ni --nodeset-input
--no --nodeset-output
--sep
--taskset
--single
--restrict
--restrict-flags
--disallowed --whole-system
--cpukind
--input -i
--input-format --if
--no-smt --no-smt=N
-q --quiet
-v --verbose
--version
-h --help
)
local cur=${COMP_WORDS[COMP_CWORD]}
local prev=${COMP_WORDS[COMP_CWORD-1]}
if [[ $COMP_CWORD == 1 || $cur == -* ]] ; then
COMPREPLY=( `compgen -W "${OPTIONS[*]}" -- "$cur"` )
else
case "$prev" in
-N | --number-of | -I | --intersect)
COMPREPLY=( `compgen -W "${TYPES[*]}" -- "$cur"` )
;;
-H | --hierarchical)
COMPREPLY=( "<type1>.<type2>..." "" )
;;
--sep)
COMPREPLY=( "<separator>" "" )
;;
-i | --input)
_filedir xml
;;
--if | --input-format)
COMPREPLY=( `compgen -W "${INPUT_FORMAT[*]}" -- "$cur"` )
;;
--restrict)
COMPREPLY=( "<bitmask>" "" )
;;
--restrict-flags)
COMPREPLY=( "<integer>" "" )
;;
--local-memory-flags)
COMPREPLY=( "<flags>" "" )
;;
--best-memattr)
COMPREPLY=( "<memattr>" "" )
;;
--cpukind)
COMPREPLY=( "<name>=<value>" "<n>" "" )
;;
esac
fi
}
complete -F _hwloc_calc hwloc-calc
_hwloc_annotate(){
local OPTIONS=(--ci --ri --cu --cd --version -h --help)
local cur=${COMP_WORDS[COMP_CWORD]}
if [[ $COMP_CWORD == 1 || $cur == -* ]] ; then
COMPREPLY=( `compgen -W "${OPTIONS[*]}" -- "$cur"`)
fi
_filedir xml
}
complete -F _hwloc_annotate hwloc-annotate
_hwloc_diff(){
local OPTIONS=(--refname
--version
-h --help
)
local cur=${COMP_WORDS[COMP_CWORD]}
local prev=${COMP_WORDS[COMP_CWORD-1]}
if [[ $COMP_CWORD == 1 || $cur == -* ]] ; then
COMPREPLY=( `compgen -W "${OPTIONS[*]}" -- "$cur"` )
else
case "$prev" in
--refname)
COMPREPLY=( "<reference topology identifier>" "")
return
;;
esac
fi
_filedir xml
}
complete -F _hwloc_diff hwloc-diff
_hwloc_patch(){
local OPTIONS=(--R --reverse
--version
-h --help
)
local cur=${COMP_WORDS[COMP_CWORD]}
if [[ $COMP_CWORD == 1 || $cur == -* ]] ; then
COMPREPLY=( `compgen -W "${OPTIONS[*]}" -- "$cur"` )
fi
_filedir xml
}
complete -F _hwloc_patch hwloc-patch
_hwloc_compress_dir(){
local OPTIONS=(-R --reverse
-v --verbose
--version
-h --help
)
local cur=${COMP_WORDS[COMP_CWORD]}
if [[ $COMP_CWORD == 1 || $cur == -* ]] ; then
COMPREPLY=( `compgen -W "${OPTIONS[*]}" -- "$cur"` )
fi
_filedir -d
}
complete -F _hwloc_compress_dir hwloc-compress-dir
_hwloc_distrib(){
local TYPES=("Machine" "Misc" "Group" "NUMANode" "MemCache" "Package" "Die" "L1" "L2" "L3" "L4" "L5" "L1i" "L2i" "L3i" "Core" "Bridge" "PCIDev" "OSDev" "PU")
local OPTIONS=(--ignore
--from
--to
--at
--reverse
--restrict
--restrict-flags
--disallowed --whole-system
--input -i
--input-format --if
--single
--taskset
-v --verbose
--version
-h --help
)
local cur=${COMP_WORDS[COMP_CWORD]}
local prev=${COMP_WORDS[COMP_CWORD-1]}
if [[ $COMP_CWORD == 1 || $cur == -* ]] ; then
COMPREPLY=( `compgen -W "${OPTIONS[*]}" -- "$cur"` )
else
case "$prev" in
--ignore | --from | --to | --at)
COMPREPLY=( `compgen -W "${TYPES[*]}" -- "$cur"` )
;;
-i | --input)
_filedir xml
;;
--if | --input-format)
COMPREPLY=( `compgen -W "${INPUT_FORMAT[*]}" -- "$cur"` )
;;
--restrict)
COMPREPLY=( "<bitmask>" "" )
;;
--restrict-flags)
COMPREPLY=( "<integer>" "" )
;;
esac
fi
}
complete -F _hwloc_distrib hwloc-distrib
_hwloc_ps(){
local OPTIONS=(-a
--pid
--name
--uid
-l --logical
-p --physical
-c --cpuset
--single-ancestor
-t --threads
-e --get-last-cpu-location
--pid-cmd
--short-name
--disallowed --whole-system
--json-server
--json-port
-v --verbose
--version
-h --help
)
local cur=${COMP_WORDS[COMP_CWORD]}
local prev=${COMP_WORDS[COMP_CWORD-1]}
if [[ $COMP_CWORD == 1 || $cur == -* ]] ; then
COMPREPLY=( `compgen -W "${OPTIONS[*]}" -- "$cur"` )
else
case "$prev" in
--name)
COMPREPLY=( "<task name>" "" )
;;
--uid)
COMPREPLY=( "<uid>" "all" "" )
;;
--pid)
COMPREPLY=( "<pid>" "" )
;;
--pid-cmd)
_filedir
;;
--json-port)
COMPREPLY=( "<port>" "" )
;;
esac
fi
}
complete -F _hwloc_ps hwloc-ps
_hwloc_gather_cpuid(){
local OPTIONS=(-c
-s --silent
--version
-h --help
)
local cur=${COMP_WORDS[COMP_CWORD]}
local prev=${COMP_WORDS[COMP_CWORD-1]}
if [[ $COMP_CWORD == 1 || $cur == -* ]] ; then
COMPREPLY=( `compgen -W "${OPTIONS[*]}" -- "$cur"` )
else
case "$prev" in
-c)
COMPREPLY=( "<index of cpu to operate on>" "" )
;;
esac
fi
}
complete -F _hwloc_gather_cpuid hwloc-gather-cpuid
_hwloc_gather_topology(){
local OPTIONS=(--io
--dmi
--no-cpuid
--keep
--version
-h --help
)
local cur=${COMP_WORDS[COMP_CWORD]}
if [[ $COMP_CWORD == 1 || $cur == -* ]] ; then
COMPREPLY=( `compgen -W "${OPTIONS[*]}" -- "$cur"` )
fi
}
complete -F _hwloc_gather_topology hwloc-gather-topology
@@ -1,163 +0,0 @@
<!-- Copyright © 2018-2019 Inria. All rights reserved. -->
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Dynamic SVG</title>
</head>
<body>
<p>
This page is an example of HTML/JS interacting with the lstopo SVG output.
</p>
<p>
Load a SVG that was exported with lstopo's <b>native</b> SVG backend
(e.g. with <tt>lstopo --of nativesvg foo.svg</tt>):
</p>
<input type="file" name="myFile" accept=".svg" onchange="openFile(event)">
<br>
<br>
<object id="img" type="image/svg+xml">
</object>
<br>
<p id='caption' style='display:none'>
Click on a box to change its background color
and replace its first text line (if any) with its SVG object id.
</p>
<p id='drag' style='display:none'>
<input type='checkbox' id='draggable' onclick='enableDrag()'>Make boxes draggable</input>
</p>
</body>
<footer>
<script type="text/javascript">
function openFile(event) {
let image = document.getElementById('img')
image.data = null
var input = event.target;
var TextReader = new FileReader()
TextReader.onload = async function(){
var parser = new DOMParser()
let blob = new Blob([TextReader.result], {type: 'image/svg+xml'})
let url = URL.createObjectURL(blob)
image.data = await url
setTimeout(function(){
document.getElementById('caption').style = ''
document.getElementById('drag').style = ''
document.getElementById("draggable").checked = false
svgObject = document.getElementById('img').contentDocument
let svgElement = svgObject.getElementById('Machine_0_rect')
if(svgObject.getElementById('Machine_0_rect')){
start(svgObject)
}else{
const h1 = document.createElement('h1')
h1.innerHTML = "Your svg file doesn't have the good format to load javascript"
document.body.appendChild(h1)
}
},200)
}
TextReader.readAsText(input.files[0], "UTF-8")
}
function enableDrag(){
let svgObject = document.getElementById('img').contentDocument
const elements = svgObject.getElementsByTagName('rect')
for (let element of elements) {
element.classList.toggle("draggable")
}
}
function start(svgObject){
makeDraggable(svgObject)
const texts = svgObject.getElementsByTagName('text')
for (let text of texts) {
text.setAttribute("style", text.getAttribute("style") + ";pointer-events:none;")
}
const elements = svgObject.getElementsByTagName('rect')
for (let element of elements) {
if(!element.id.includes("Bridge")){
element.addEventListener('click', function(e) {
changeColor(svgObject, e.target)
changeText(svgObject, e.target)
})
}
}
}
function changeColor(svgObject, element){
oldColor = element.getAttribute("saveColor")
if(!oldColor){
element.setAttribute("saveColor", element.getAttribute("fill"))
element.setAttribute("fill", "red")
}else{
element.setAttribute("fill", oldColor)
element.removeAttribute("saveColor")
}
}
function changeText(svgObject, element){
if(element.id == "")
return
const text = svgObject.getElementById(element.id.replace('rect', 'text'))
let textContent = element.getAttribute("saveText")
if(!textContent){
element.setAttribute("saveText", text.innerHTML)
textContent = element.id
}else{
element.removeAttribute("saveText")
}
let svg = svgObject.documentElement;
let svgNS = svg.namespaceURI;
let newText = text.cloneNode(false)
newText.appendChild(svgObject.createTextNode(textContent))
svg.removeChild(text)
svg.appendChild(newText)
}
function makeDraggable(svgObject) {
let selectedElement = null
let text = null
let marginTextX = null
let marginTextY = null
svgObject.addEventListener('mousedown', startDrag)
svgObject.addEventListener('mousemove', drag)
svgObject.addEventListener('mouseup', endDrag)
svgObject.addEventListener('mouseleave', endDrag)
function startDrag(evt) {
if (evt.target.classList.contains('draggable')) {
selectedElement = evt.target;
text = getText(svgObject, selectedElement.id)
marginTextX = text.getAttribute("x") - selectedElement.getAttribute("x")
marginTextY = text.getAttribute("y") - selectedElement.getAttribute("y")
}
}
function drag(evt) {
if (selectedElement) {
evt.preventDefault();
let textDragX = evt.clientX + marginTextX
let textDragY = evt.clientY + marginTextY
let dragX = evt.clientX;
let dragY = evt.clientY;
selectedElement.setAttribute("x", dragX);
selectedElement.setAttribute("y", dragY);
text.setAttribute("x", textDragX);
text.setAttribute("y", textDragY);
}
}
function endDrag(evt) {
selectedElement = null
}
}
</script>
</footer>
</html>
Binary file not shown.
Binary file not shown.
-61
View File
@@ -1,61 +0,0 @@
This tool displays process and thread binding in an interative web page.
1) Basic Usage
Run the hwloc-ps tool in JSON server mode:
$ hwloc-ps --json-server
server running on port 8888...
Export the topology as a SVG file using the native backend:
$ lstopo filename.svg --of nativesvg
Now run the client side for displaying the binding:
$ cd /path/to/hwloc-ps.www/
$ node client.js /path/to/filename.svg
This should open a webpage in your browser.
Otherwise add -u to see the URL that you should open (usually http://localhost:3000).
2) Installing node.js and JS dependencies
The "node" command is available in the "nodejs" package in most Linux distributions,
but you should rather install the "npm" package to get additional utilities:
# apt instal npm
# yum install npm
Then install the dependencies needed by client.js:
$ cd /path/to/hwloc-ps.www/
$ npm install
If you don't have write-access to the hwloc-ps.www/ directory,
copy it somewhere else, run "npm install" from there,
and then run the client from there:
$ cp -a /path/to/hwloc-ps.www/ $HOME/myhwloc-ps.www/
$ cd $HOME/myhwloc-ps.www/
$ npm install
$ node client.js /path/to/filename.svg
3) Running on a remote server
This tool is often useful for debugging process placement on remote servers, hence:
* hwloc-ps and lstopo should run on that remote server
(this requires a recent hwloc on the remote side).
* you must copy the SVG file back to your machine:
$ scp target:/path/to/filename.svg .
* if the target machine port 8888 is not directly accessible, you may
have to forward its 8888 port:
$ ssh target -L 8888:localhost:8888 -Nf
@@ -1,65 +0,0 @@
<!-- Copyright © 2018-2019 Inria. All rights reserved. -->
<!doctype html>
<html lang="en">
<head>
<link rel="stylesheet" type="text/css" href="/stylecss">
<link rel="stylesheet" type="text/css" href="/maincss">
<meta charset="utf-8">
<title>Dynamic SVG</title>
<script type='text/javascript' src='/js'></script>
</head>
<ul class='navul'>
<li class='navli'><a onclick='clearProc()'>Clear processes</a></li>
<li class='navli'><a class='procButton' type='all'>All processes</a></li>
<li class='navli'><a class='procButton' type='bound'>Bound processes</a></li>
<li class='navli'><label for="threads">Show threads<input id='threads' class='checkbox' type="checkbox" name="threads"></label></li>
<li class='navli'><label for="lastLocation">Show last location<input id='lastcpulocation' class='checkbox' type="checkbox" name="lastLocation"></label></li>
<li class='navli'><input class='hide-mobile' type='text' placeholder='PID or Name' value='' id='searchId'/> <input class='button hide-mobile' type='button' value='Search process' onclick="procByid()"/></li>
</ul>
<body style='text-align: center; background-color: #959ba5'>
<object style='margin-top: 50px' id="svg-object" type="image/svg+xml" data="/svg">
Your browser does not support SVG.
</object>
<br>
<div style="display: inline-block;">
<div id='info' class='hidden'>
<ul>
<li></li>
<li></li>
<li></li>
<li></li>
</ul>
</div>
<div id='info-not-found' class='hidden'>
<ul style="list-style: none;">
<li> Process : not found </li>
</ul>
</div>
</div>
<div id='processTable' class="table100 ver2 m-b-110 hidden">
<div class="table100-head">
<table>
<thead>
<tr class="row100 head">
<th class="cell100 column1">Process id</th>
<th class="cell100 column2">Name</th>
<th class="cell100 column3">Displayed <input id='mainCheck' checked='true' type="checkbox"></input> </th>
</tr>
</thead>
</table>
</div>
<div class="table100-body js-pscroll">
<table>
<tbody id='table'>
</tbody>
</table>
</div>
</div>
</body>
</html>
@@ -1,115 +0,0 @@
/* Copyright © 2019 Inria. All rights reserved. */
/*//////////////////////////////////////////////////////////////////
[ Scroll bar ]*/
.js-pscroll {
position: relative;
overflow: hidden;
}
.table100 .ps__rail-y {
width: 9px;
background-color: transparent;
opacity: 1 !important;
right: 5px;
}
.table100 .ps__rail-y::before {
content: "";
display: block;
position: absolute;
background-color: #ebebeb;
border-radius: 5px;
width: 50%;
height: calc(100% - 30px);
top: 15px;
}
.table100 .ps__rail-y .ps__thumb-y {
width: 50%;
background-color: transparent;
opacity: 1 !important;
}
.table100 .ps__rail-y .ps__thumb-y::before {
content: "";
display: block;
position: absolute;
background-color: #cccccc;
border-radius: 5px;
width: 50%;
height: calc(100% - 30px);
left: 0;
top: 15px;
}
/*//////////////////////////////////////////////////////////////////
[ Table ]*/
.table100 {
margin-top: 30px;
width: 22.5%;
background-color: #5d5e60;
min-width: 250px;
left: 38.8%;
}
.column1{
left:0;
}
th {
width: 33%;
font-weight: unset;
}
td {
width: 33%;
}
tr, table, thead {
width: 100%;
}
.table100-head th {
padding-top: 10px;
padding-bottom: 10px;
}
/*==================================================================
Table*/
.table100 {
position: relative;
padding-top: 60px;
}
.table100-head {
position: absolute;
width: 100%;
top: 0;
left: 0;
}
.table100-body {
max-height: 585px;
overflow: auto;
}
.table100.ver2 th {
font-size: 13px;
color: white;
line-height: 1.4;
background-color: transparent;
}
.table100.ver2 td {
font-size: 11px;
color: white;
line-height: 1.4;
padding-left: 22px;
padding-right: 17px;
}
.table100.ver2 {
border-radius: 10px;
}
@@ -1,489 +0,0 @@
/* Copyright © 2019 Inria. All rights reserved. */
function start(svgObject){
const texts = svgObject.getElementsByTagName('text')
for (let text of texts) {
text.setAttribute("style", text.getAttribute("style") + "; pointer-events:none")
}
}
async function createProcesses(svgdoc, req, json = null){
await clear(svgdoc)
clearTable()
if(!json){
response = await fetch("/" + req)
json = await response.json()
}
json.forEach(proc => {
displayProcess(svgdoc, proc, req)
})
createTooltip(svgdoc)
if (/^proc\/\d+$/.test(req)) {
//only show if single PID
displayInfo(svgdoc, json)
//threads auto-enabled for single PID
document.getElementById('threads').checked = true
}
}
async function displayProcess(svgdoc, proc, req = null){
if(!proc.object)
return
//create table except when looking at a single process
if(!/proc\/\d+$/.test(req))
fillTable(svgdoc, proc)
bullet(svgdoc, proc, "")
text(svgdoc, proc, "")
if(proc.threads){
proc.threads.forEach(async thread =>{
if(thread.object){
bullet(svgdoc, thread, "thread")
text(svgdoc, thread, "thread")
}
})
}
}
function bullet(svgdoc, obj, objType){
let bulletCircle = svgdoc.getElementById("bulletCircle" + objType + "_" + obj.object.replace(':','_'))
//if a bullet doesn't already exist, if it does, just add the process id to the bullet attributes
if(!bulletCircle){
let id = obj.object.replace(':','_')+"_rect"
let rect = svgdoc.getElementById(id)
bulletCircle = svgdoc.createElementNS("http://www.w3.org/2000/svg","rect")
//difference thread and process
if(objType === "thread"){
bulletCircle.setAttribute("thread", true)
bulletCircle.setAttribute("height", "15")
bulletCircle.setAttribute("fill", "#7cacf9")
bulletCircle.setAttribute("y", rect.y.animVal.value + 12)
}else{
bulletCircle.setAttribute("y", rect.y.animVal.value - 5)
bulletCircle.setAttribute("height", "15")
bulletCircle.setAttribute("fill", "#FFFFFF")
}
//set the bullet in the middle if the process is on machine_O
if(id == "Machine_0_rect"){
const svg = svgdoc.getElementsByTagName('svg')[0]
bulletCircle.setAttribute("x", svg.width.baseVal.value / 2 - 10)
bulletCircle.setAttribute("y", 5)
if(objType === "thread"){
bulletCircle.setAttribute("x", svg.width.baseVal.value / 2 + 45)
bulletCircle.setAttribute("y", 5)
}
}else{
bulletCircle.setAttribute("x", rect.x.animVal.value-5)
}
bulletCircle.setAttribute("rx", 10)
bulletCircle.setAttribute("ry", 10)
bulletCircle.setAttribute("circle", true)
bulletCircle.setAttribute("stroke-width", "1")
bulletCircle.setAttribute("stroke", "#000000")
bulletCircle.classList.add("tooltip-trigger")
rect.parentNode.appendChild(bulletCircle)
bulletCircle.id = "bulletCircle" + objType + "_" + obj.object.replace(':','_')
let secondId
if(objType === "thread")
secondId = "thread id : " + obj.PID
else
secondId = "process id : " + obj.PID
bulletCircle.setAttribute('secondId', secondId)
}else {
let secondId = bulletCircle.getAttribute('secondId')
if(objType === "thread")
secondId += ';' + "thread id : " + obj.PID
else
secondId += ';' + "process id : " + obj.PID
bulletCircle.setAttribute('secondId', secondId)
}
}
function text(svgdoc, obj, objType){
let id = obj.object.replace(':','_')+"_rect"
let rect = svgdoc.getElementById(id)
let bulletText = svgdoc.createElementNS("http://www.w3.org/2000/svg","text")
let bulletCircle = svgdoc.getElementById("bulletCircle" + objType + "_" + obj.object.replace(':','_'))
//if a bullet doesn't already exist, if it does, increment the text
if(!svgdoc.getElementById("bulletText" + objType + "_" + obj.object.replace(':','_'))){
bulletText.setAttribute("circle", true)
//set the text in the middle if the process is on machine_O
if(id == "Machine_0_rect"){
const svg = svgdoc.getElementsByTagName('svg')[0]
bulletText.setAttribute("x", svg.width.baseVal.value / 2 - 3)
bulletText.setAttribute("y", 15)
if(objType === "thread"){
bulletText.setAttribute("x", svg.width.baseVal.value / 2 + 52)
bulletText.setAttribute("y", 15)
}
}else{
bulletText.setAttribute("x", rect.x.animVal.value+2)
bulletText.setAttribute("y", rect.y.animVal.value+6)
}
//difference thread and process
if(objType === "thread" && id != "Machine_0_rect"){
bulletText.setAttribute("thread", true)
bulletText.setAttribute("y", rect.y.animVal.value+22)
}
bulletText.setAttribute("style", bulletText.getAttribute("style") + "; pointer-events:none")
bulletText.setAttribute("font-size", "10px")
updateBulletText(bulletText, obj.PID, bulletCircle)
bulletText.id = "bulletText" + objType + "_" + obj.object.replace(':','_')
rect.parentNode.appendChild(bulletText)
}else{
let text = svgdoc.getElementById("bulletText" + objType + "_" + obj.object.replace(':','_'))
updateBulletText(text, findPid(text, '+'), bulletCircle)
//set the text in the middle if the process is on machine_O
if(id == "Machine_0_rect"){
if (text.textContent == 10)
text.setAttribute("x", parseInt(text.getAttribute('x')) - 3)
else if(text.textContent == 100)
text.setAttribute("x", parseInt(text.getAttribute('x')) - 4)
return
}
}
}
async function updateBulletText(text, pid, bulletCircle){
text.textContent = await pid
let length = text.getComputedTextLength()
bulletCircle.setAttribute("width", length + 15)
}
function findPid(text, op){
let nb
if(!text.getAttribute('nb')){
nb = "[2]"
text.setAttribute('nb', nb)
}else{
nb = text.getAttribute('nb')
nb = nb.replace('[','')
nb = nb.replace(']','')
if(op == '+')
nb = parseInt(nb) + 1
else{
nb = parseInt(nb) - 1
}
nb = '[' + nb + ']'
text.setAttribute('nb', nb)
}
return nb
}
function clear(svgdoc){
document.getElementById('searchId').value = ''
const info = document.getElementById('info')
info.classList = 'hidden'
const infoNotFound = document.getElementById('info-not-found')
infoNotFound.classList = 'hidden'
svgElements = svgdoc.getElementsByTagName('svg')[0].children
let i = 0;
for(element of svgElements){
if(element.id.includes('bulletCircle'))
i += 2
}
if(i == 0)
return
for(i ; i >= 0 ; i--){
svgElements[svgElements.length - 1].remove()
}
}
function createTooltip(svgdoc){
if(svgdoc.getElementById('tooltip'))
svgdoc.getElementById('tooltip').remove()
//Create tooltip to display process id
const g = svgdoc.createElementNS("http://www.w3.org/2000/svg","g")
const blackRect = svgdoc.createElementNS("http://www.w3.org/2000/svg",'rect')
const whiteRect = svgdoc.createElementNS("http://www.w3.org/2000/svg",'rect')
const tooltip = svgdoc.createElementNS("http://www.w3.org/2000/svg",'text')
blackRect.setAttribute('fill','black')
blackRect.setAttribute('opacity','0.4')
blackRect.setAttribute('rx','2')
blackRect.setAttribute('ry','2')
blackRect.setAttribute('x','2')
blackRect.setAttribute('y','-8')
blackRect.setAttribute('height','11')
blackRect.setAttribute('opacity','0.4')
whiteRect.setAttribute('y','-10')
whiteRect.setAttribute('fill','white')
whiteRect.setAttribute('rx','2')
whiteRect.setAttribute('ry','2')
whiteRect.setAttribute('height','11')
tooltip.setAttribute('x','4')
tooltip.setAttribute('y','6')
g.setAttribute('visibility', 'hidden')
g.id = "tooltip"
g.appendChild(blackRect)
g.appendChild(whiteRect)
g.appendChild(tooltip)
svgdoc.getElementsByTagName('svg')[0].appendChild(g)
let triggers = svgdoc.getElementsByClassName('tooltip-trigger')
for (let i = 0; i < triggers.length; i++) {
triggers[i].onmousemove = showTooltip
triggers[i].onmouseout = hideTooltip
triggers[i].onclick = async function(){
//on click : display process info for the first process in the bullet
procs = triggers[i].getAttribute('secondId').split(";")
let data = new Array()
response = await fetch("/json")
json = await response.json()
await procs.forEach(proc => {
json.forEach(jsonProcess => {
if(proc.substring(13) == jsonProcess.PID)
data.push(jsonProcess)
})
})
let req = data.length == 1 ? "proc/" + data[0].PID : null
createProcesses(svgdoc, req, data)
}
}
function showTooltip(evt) {
const tooltip = svgdoc.getElementById('tooltip')
let tooltipText = tooltip.getElementsByTagName('text')[0]
let tooltipRects = tooltip.getElementsByTagName('rect')
//clear tooltip
while(tooltipText.firstChild){
tooltipText.removeChild(tooltipText.firstChild)
for (let i = 0; i < tooltipRects.length; i++) {
tooltipRects[i].setAttribute("height", parseInt(tooltipRects[i].getAttribute("height")) - 15)
}
}
//display all processes id in the bullet
let text = evt.target.getAttribute('secondId')
let tspan
text = text.split(';')
let length = 0
for (str of text ) {
//create the text element
tspan = svgdoc.createElementNS("http://www.w3.org/2000/svg",'tspan')
if(text.indexOf(str) !== 0)
tspan.setAttribute('dy', '1em')
tspan.setAttribute('x', '0')
tspan.textContent = str
tooltipText.appendChild(tspan)
//find the length of the longest text
if(tspan.getComputedTextLength() > length)
length = tspan.getComputedTextLength()
//ajust the height of the tooltip element ( and its shadow )
for (let i = 0; i < tooltipRects.length; i++) {
tooltipRects[i].setAttribute("height", parseInt(tooltipRects[i].getAttribute("height")) + 15)
}
//display "..." if there is more than 5 processes
if(text.indexOf(str) === 5){
tspan.textContent = '\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0\u00A0...'
tooltipText.appendChild(tspan)
break
}
}
//set the tooltip ( and its shadow ) width according to the longest element
for (let i = 0; i < tooltipRects.length; i++) {
tooltipRects[i].setAttributeNS(null, "width", length + 8)
}
//display the tooltip at the mouse coordonates
let CTM = svgdoc.getElementsByTagName('svg')[0].getScreenCTM()
let x = (evt.clientX - CTM.e + 6) / CTM.a;
let y = (evt.clientY - CTM.f + 20) / CTM.d;
tooltip.setAttributeNS(null, "transform", "translate(" + x + " " + y + ")");
tooltip.setAttributeNS(null, "visibility", "visible")
}
function hideTooltip() {
const tooltip = svgdoc.getElementById('tooltip')
tooltip.setAttributeNS(null, "visibility", "hidden")
}
}
async function displayInfo(svgdoc, data){
//handle 2 div : one if the process is found, and one if it isn't
const info = document.getElementById('info')
const infoNotFound = document.getElementById('info-not-found')
info.classList = 'hidden'
infoNotFound.classList = 'hidden'
if(!data[0].object){
infoNotFound.classList.toggle('hidden')
return
}
const infos = info.children[0].children
infos[0].innerHTML = 'Process: ' + data[0].PID
infos[1].innerHTML = 'Name: ' + data[0].name
infos[2].innerHTML = 'Object: ' + data[0].object.replace(':',' L#')
if(data[0].threads){
infos[3].innerHTML = 'Threads: ' + (data[0].threads.length - 1)
}else{
infos[3].classList = 'hidden'
}
info.classList.toggle('hidden')
}
function fillTable(svgdoc, proc){
document.getElementById('processTable').classList = "table100 ver2 m-b-110"
const table = document.getElementById('table')
const tr = document.createElement('tr')
const td = document.createElement('td')
const td2 = document.createElement('td')
const td3 = document.createElement('td')
const checkbox = document.getElementById('mainCheck')
tr.classList.add("row100", "head")
td.classList.add("cell100", "column1")
td2.classList.add("cell100", "column1")
td3.classList.add("cell100", "column1")
tr.setAttribute("object", proc.object)
td.innerHTML = proc.PID
td2.innerHTML = proc.name
td3.innerHTML = "<input class='subCheck' checked='true' type='checkbox'>"
td3.children[0].addEventListener('change', displayTableElement)
checkbox.checked = true
checkbox.onchange = changeAll
tr.appendChild(td)
tr.appendChild(td2)
tr.appendChild(td3)
table.appendChild(tr)
//toggle dispay - hide according to checkbox value
function displayTableElement(event){
const tr = event.target.parentElement.parentElement
const tds = tr.children
const proc = { PID : tds[0].innerHTML, name : tds[1].innerHTML, object : tr.getAttribute('object') }
if(event.target.checked == false){
const element = svgdoc.getElementById("bulletCircle" + "_" + proc.object.replace(':','_'))
removeProc(element, proc)
}else{
bullet(svgdoc, proc, "")
text(svgdoc, proc, "")
createTooltip(svgdoc)
}
}
function removeProc(element, proc){
let id = element.id
let text = svgdoc.getElementById(id.replace('bulletCircle', 'bulletText'))
let secondId = element.getAttribute('secondId').replace('process id : ' + proc.PID + ';', '')
if(!text.getAttribute('nb') || text.getAttribute('nb') == '[1]'){
text.remove()
element.remove()
}else{
updateBulletText(text, findPid(text, '-'), element)
}
element.setAttribute('secondId', secondId)
}
//handle click on main checkbox -> set all checkbox value to its value
function changeAll(event){
const checkboxes = document.getElementsByClassName('subCheck')
size = checkboxes.length
for(let i = 0 ; i < size ; i++ ){
if(checkboxes[i].checked != event.target.checked){
checkboxes[i].checked = event.target.checked
displayTableElement({target: checkboxes[i]})
}
}
}
}
function clearProc(){
document.getElementById('searchId').value = ""
const checkboxes = document.getElementsByClassName('checkbox')
for( let i = 0 ; i < checkboxes.length ; i++ ){
checkboxes[i].checked = false
}
let svgObject = document.getElementById('svg-object').contentDocument
clear(svgObject)
}
function clearTable(){
const table = document.getElementById("table");
while (table.firstChild) {
table.removeChild(table.firstChild);
}
document.getElementById("processTable").classList = "table100 ver2 m-b-110 hidden"
}
function handleProcButton(){
let functionIsRunning = false
//use function is running so that the function doesn't run twice if the user double click.
async function addProc(req){
if (!functionIsRunning) {
functionIsRunning = true
if(req == 'bound' || req == 'all'){
clearProc()
clearTable()
}
let svgObject = document.getElementById('svg-object').contentDocument
await createProcesses(svgObject, req)
functionIsRunning = false
}
}
const procButtons = document.getElementsByClassName('procButton')
for(let i = 0 ; i < procButtons.length ; i++){
procButtons[i].addEventListener('click', function(){
addProc(procButtons[i].type)
})
}
}
function handleCheckbox(){
const checkboxes = document.getElementsByClassName('checkbox')
for( let i = 0 ; i < checkboxes.length ; i++ ){
checkboxes[i].checked = false
checkboxes[i].addEventListener('change',function(e){
clearTable()
let svgObject = document.getElementById('svg-object').contentDocument
createProcesses(svgObject, e.target.id)
})
}
}
function procByid(){
let svgObject = document.getElementById('svg-object').contentDocument
let id = document.getElementById('searchId').value
clearProc()
createProcesses(svgObject, 'proc/'+id)
}
//time out so that the svg has the time to load
setTimeout(function() {
handleCheckbox()
handleProcButton()
const input = document.getElementById('searchId')
input.value = ''
input.addEventListener('keyup',function(event){
if(event.keyCode === 13){
event.preventDefault()
procByid()
}
})
let svgObject = document.getElementById('svg-object').contentDocument
let svgElement = svgObject.getElementById('Machine_0_rect')
if(svgObject.getElementById('Machine_0_rect')){
createProcesses(svgObject, 'bound')
start(svgObject)
}else{
const h1 = document.createElement('h1')
h1.innerHTML = "Your svg file doesn't have the good format to load javascript"
document.body.appendChild(h1)
}
}, 200)
@@ -1,142 +0,0 @@
/* Copyright © 2019 Inria. All rights reserved. */
.navul {
position: fixed;
left: 0;
top: 0;
width: 100%;
list-style-type: none;
margin: 0;
padding: 0;
overflow: hidden;
background-color: #5d5e60;
}
.navli {
float: left;
}
li a{
display: block;
color: white;
text-align: center;
padding: 14px 16px;
text-decoration: none;
}
.draggable {
display: inline;
}
/* Change the link color to #111 (black) on hover */
li a:hover{
background-color: #111;
}
label {
display: inline-block;
padding-left: 15px;
text-indent: -15px;
color: white;
text-align: center;
padding: 14px 16px;
text-decoration: none;
}
.checkbox {
width: 13px;
height: 13px;
padding: 0;
margin:0;
vertical-align: bottom;
position: relative;
top: -2px;
*overflow: hidden;
margin-left: 14px;
}
#mainCheck{
width: 13px;
height: 13px;
padding: 0;
margin:0;
vertical-align: bottom;
position: relative;
top: -2px;
*overflow: hidden;
}
input{
margin-top:7px;
}
.button {
position:fixed;
right: 10px;
background-color: #7f8082;
border: none;
color: white;
padding: 7px 16px;
text-align: center;
text-decoration: none;
display: inline-block;
font-size: 16px;
border-radius: 4px;
-webkit-transition-duration: 0.4s; /* Safari */
transition-duration: 0.4s;
}
#searchId{
position: fixed;
right: 150px;
}
.button:hover {
background-color: #111; /* Green */
color: white;
}
#info{
padding-top : 5px;
color: black;
border-radius: 5px;
background-color: white;
width:300px;
min-height:200px;
box-shadow: 5px 10px #888888;
text-align: left;
}
#info-not-found{
padding-top : 5px;
color: black;
border: 2x solid black;
border-radius: 5px;
background-color: white;
width:300px;
min-height:200px;
box-shadow: 5px 10px #888888;
text-align: left;
}
.hidden{
display:none;
}
@media only screen and (max-width: 1175px) {
.show-mobile {
display: block;
}
.hide-mobile {
display: none;
}
}
@media only screen and (min-width: 1176px) {
.show-mobile {
display: none;
}
.hide-mobile {
display: block;
}
}
-188
View File
@@ -1,188 +0,0 @@
/* Copyright © 2019 Inria. All rights reserved. */
var express = require('express')
var path = require('path')
var app = express()
var net = require('net')
var HOST = 'localhost'
var HPPORT = 8888
var NPORT = 3000
var verbose = 0
var open = 1
var fs = require('fs')
var open = require("open")
var lastRequest = ''
var client = new net.Socket()
var svg
var json
function usage() {
console.log(path.basename(process.argv[0]) + " " + path.basename(process.argv[1]) + " [options] <file.svg>")
console.log(" SVG file <file.svg> must be generated with lstopo --of nativesvg <file.svg>")
console.log("Options:")
console.log(" --hp <port> Change hwloc-ps JSON server port (default is "+HPPORT+")")
console.log(" --np <port> Change node port (default is "+NPORT+")")
console.log(" -u Display the webpage URL instead of opening it")
console.log(" -v --verbose Increase verbosity")
console.log(" -h --help Show this help")
}
var currentarg = 2
while(process.argv.length > currentarg){
if(process.argv[currentarg] === '-h' || process.argv[currentarg] === '-help'){
usage()
return
}else if (process.argv[currentarg] === '-v' || process.argv[currentarg] === '--verbose'){
verbose++
currentarg++
}else if (process.argv[currentarg] === '-u'){
open = 0
currentarg++
}else if (process.argv[currentarg] === '--hp'){
if(currentarg+2 > process.argv.length){
console.err("Missing argument after --hp")
usage()
return
}
HPPORT = process.argv[currentarg + 1]
currentarg += 2
}else if (process.argv[currentarg] === '--np'){
if(currentarg+2 > process.argv.length){
console.err("Missing argument after --np")
usage()
return
}
NPORT = process.argv[currentarg + 1]
currentarg += 2
}else{
if(svg != undefined){
console.err("Unexpected parameter after SVG filename.")
usage()
return
}
svg = process.argv[currentarg]
currentarg++
}
}
if(svg === undefined){
console.err("Missing SVG filename.")
usage()
return
}
client.on('data', function(data) {
if (verbose > 0)
console.log('##########################\n'
+ 'Client received:\n'
+ data
+ '##########################\n')
json += data
})
client.on('close', function() {
console.log('Client closed')
})
client.on('error', function(err) {
console.error(err)
})
app.get('/svg', function (req, res, next) {
res.setHeader('Content-Type', 'image/svg+xml')
res.sendFile(path.resolve(__dirname, svg))
})
app.get('/js', function (req, res, next) {
res.setHeader('Content-Type', 'text/javascript')
res.sendFile(path.join(__dirname, './assets/script.js'))
})
app.get('/json', function (req, res, next) {
res.setHeader('Content-Type', 'application/json')
res.send(json)
})
app.get('/stylecss', function (req, res, next) {
res.setHeader('Content-Type', 'text/css')
res.sendFile(path.join(__dirname, './assets/style.css'))
})
app.get('/maincss', function (req, res, next) {
res.setHeader('Content-Type', 'text/css')
res.sendFile(path.join(__dirname, './assets/main.css'))
})
app.get('/', function(req, res){
res.sendFile(path.join(__dirname+'/assets/index.html'))
})
app.get('/bound', async (req, res) =>{
json = ""
lastRequest = 'bound'
await client.write(lastRequest)
setTimeout(function(){
res.setHeader('Content-Type', 'application/json')
res.send(JSON.parse(json))
}, 500)
})
app.get('/all', async (req, res) =>{
json = ""
lastRequest = 'all'
await client.write(lastRequest)
setTimeout(function(){
res.setHeader('Content-Type', 'application/json')
res.send(json)
}, 500)
})
app.get('/proc/:filter', async (req, res) =>{
json = ""
if (/^\d+$/.test(req.params.filter))
lastRequest = 'threads pid=' + req.params.filter
else
lastRequest = 'name=' + req.params.filter
await client.write(lastRequest)
setTimeout(function(){
res.setHeader('Content-Type', 'application/json')
res.send(json)
}, 500)
})
app.get('/threads', async (req, res) =>{
json = ""
if(!lastRequest.includes('threads'))
lastRequest = 'threads ' + lastRequest
else
lastRequest = lastRequest.replace('threads ', '')
await client.write(lastRequest)
setTimeout(function(){
res.setHeader('Content-Type', 'application/json')
res.send(json)
}, 500)
})
app.get('/lastcpulocation', async (req, res) =>{
json = ""
if(!lastRequest.includes('lastcpulocation'))
lastRequest = 'lastcpulocation ' + lastRequest
else
lastRequest = lastRequest.replace('lastcpulocation ', '')
await client.write(lastRequest)
setTimeout(function(){
res.setHeader('Content-Type', 'application/json')
res.send(json)
}, 500)
})
client.connect(HPPORT, HOST, function() {
console.log('Client connected to hwloc-ps JSON server running on ' + HOST + ':' + HPPORT)
let serv = app.listen(NPORT)
if(open){
open("http://localhost:" + NPORT)
}else{
console.log("Page is available from http://localhost:" + NPORT)
}
})
@@ -1,17 +0,0 @@
{
"name": "js",
"version": "1.0.0",
"description": "",
"main": "client.js",
"scripts": {
"test": "echo \"Error: no test specified\" && exit 1",
"grunt": "grunt",
"server": "node server.js"
},
"author": "",
"license": "ISC",
"dependencies": {
"express": "^4.16.4",
"open": ">=6.0.0"
}
}
-161
View File
@@ -1,161 +0,0 @@
# Copyright © 2012-2018 Inria. All rights reserved.
# See COPYING in top-level directory.
# suppressions file to be passed to valgrind with
# --suppressions=/path/to/hwloc-valgrind.supp
# zlib (brought by libpci or libxml2) doesn't cleanup its global state
{
inflate_init
Memcheck:Cond
fun:inflateReset2
fun:inflateInit2_
}
# hwloc cannot free the global parser (with xmlCleanupParser()) because other threads may be using it
{
xml_init_parser
Memcheck:Leak
...
fun:xmlInitParser
}
# hwloc cannot free the global xml dict RMutex because it cannot call xmlCleanupParser() as explained above
{
xml_dict_create_new_rmutex
Memcheck:Leak
fun:malloc
fun:xmlNewRMutex
...
fun:xmlDictCreate
}
# ltdl dlopen global state?
{
ltdl_dlopen_doit_leak
Memcheck:Leak
...
fun:dl_open_worker
fun:_dl_catch_error
fun:_dl_open
fun:dlopen_doit
}
# ltdl_dlclose_leak
{
ltdl_dlclose_leak
Memcheck:Leak
...
fun:_dl_close_worker
fun:_dl_close
...
fun:dlclose
}
# lt_dlforeachfile abusing paths
{
lt_dlforeachfile_addr8
Memcheck:Addr8
fun:_wordcopy_fwd_dest_aligned
fun:__GI_memmove
fun:argz_insert
...
fun:lt_dlforeachfile
}
# cuda
{
cuda_leak
Memcheck:Leak
...
obj:*libcuda*
}
# nvml
{
nvmlInit_cond
Memcheck:Cond
...
obj:*nvidia-ml*
...
fun:nvmlInit
}
# amd opencl
{
atical_leak
Memcheck:Leak
...
obj:*libatical*
}
{
atical_cond
Memcheck:Cond
...
obj:*libatical*
}
{
amdocl_leak
Memcheck:Leak
...
obj:*libamdocl*
}
{
amdocl_param
Memcheck:Param
write(buf)
fun:*write*
obj:*libamdocl*
}
{
opencl_leak
Memcheck:Leak
...
obj:*libOpenCL*
...
fun:clGetPlatformIDs
}
{
libatiadl_xcb_leak
Memcheck:Leak
...
obj:*libxcb*
...
fun:XOpenDisplay
...
obj:*libatiadl*
}
# libpciaccess global state leak
{
libpciaccess_device_name_leak
Memcheck:Leak
...
fun:pci_device_get_device_name
fun:hwloc_look_pci
}
{
libpciaccess_leak
Memcheck:Leak
...
obj:*libpciaccess*
...
fun:hwloc_look_pci
}
# libudev global hashes
{
libudev_hashmap_property
Memcheck:Leak
fun:malloc
...
fun:udev_device_get_property_value
}
{
libudev_hashmap_sysname
Memcheck:Leak
fun:malloc
...
fun:udev_device_new_from_subsystem_sysname
}
-73
View File
@@ -1,73 +0,0 @@
<!--
Copyright © 2009 CNRS
Copyright © 2009-2017 Inria. All rights reserved.
Copyright © 2009-2011 Université Bordeaux.
See COPYING in top-level directory.
This is the old DTD for hwloc v1.x XMLs and diff XMLs.
-->
<!ELEMENT topology (object)+>
<!ELEMENT root (object)+>
<!ELEMENT object (page_type*,info*,distances*,userdata*,object*)>
<!ATTLIST object type (System | Machine | Misc | Group | NUMANode | Socket | Package | Cache | Core | PU | Bridge | PCIDev | OSDev) #REQUIRED>
<!ATTLIST object os_level CDATA "-1" >
<!ATTLIST object os_index CDATA "-1" >
<!ATTLIST object name CDATA "" >
<!ATTLIST object local_memory CDATA "0" >
<!ATTLIST object cache_size CDATA "0" >
<!ATTLIST object cache_linesize CDATA "0" >
<!ATTLIST object cache_associativity CDATA "0" >
<!ATTLIST object cache_type CDATA "0" >
<!ATTLIST object huge_page_size_kB CDATA "0" >
<!ATTLIST object huge_page_free CDATA "0" >
<!ATTLIST object depth CDATA "-1" >
<!ATTLIST object cpuset CDATA "0" >
<!ATTLIST object complete_cpuset CDATA "" >
<!ATTLIST object online_cpuset CDATA "" >
<!ATTLIST object allowed_cpuset CDATA "" >
<!ATTLIST object nodeset CDATA "" >
<!ATTLIST object complete_nodeset CDATA "" >
<!ATTLIST object allowed_nodeset CDATA "" >
<!ATTLIST object bridge_type CDATA "" >
<!ATTLIST object bridge_pci CDATA "" >
<!ATTLIST object pci_busid CDATA "" >
<!ATTLIST object pci_type CDATA "" >
<!ATTLIST object pci_link_speed CDATA "0." >
<!ATTLIST object osdev_type CDATA "" >
<!ELEMENT page_type EMPTY>
<!ATTLIST page_type size CDATA #REQUIRED>
<!ATTLIST page_type count CDATA #REQUIRED>
<!ELEMENT info EMPTY>
<!ATTLIST info name CDATA #REQUIRED>
<!ATTLIST info value CDATA #REQUIRED>
<!ELEMENT distances (latency*)>
<!ATTLIST distances nbobjs CDATA #REQUIRED>
<!ATTLIST distances relative_depth CDATA #REQUIRED>
<!ATTLIST distances latency_base CDATA #REQUIRED>
<!ELEMENT latency EMPTY>
<!ATTLIST latency value CDATA #REQUIRED>
<!ELEMENT userdata (#PCDATA)>
<!ATTLIST userdata name CDATA "" >
<!ATTLIST userdata length CDATA "0" >
<!ATTLIST userdata encoding CDATA "" >
<!ELEMENT topologydiff (diff)*>
<!ATTLIST topologydiff refname CDATA "">
<!ELEMENT diff EMPTY>
<!ATTLIST diff type CDATA #REQUIRED>
<!ATTLIST diff obj_depth CDATA "-1" >
<!ATTLIST diff obj_index CDATA "-1" >
<!ATTLIST diff obj_attr_type CDATA "-1" >
<!ATTLIST diff obj_attr_index CDATA "-1" >
<!ATTLIST diff obj_attr_name CDATA "" >
<!ATTLIST diff obj_attr_newvalue CDATA "" >
<!ATTLIST diff obj_attr_oldvalue CDATA "" >
-21
View File
@@ -1,21 +0,0 @@
<!--
Copyright © 2009 CNRS
Copyright © 2009-2017 Inria. All rights reserved.
Copyright © 2009-2011 Université Bordeaux.
See COPYING in top-level directory.
This is the DTD for hwloc v2.x diff XMLs.
-->
<!ELEMENT topologydiff (diff)*>
<!ATTLIST topologydiff refname CDATA "">
<!ELEMENT diff EMPTY>
<!ATTLIST diff type CDATA #REQUIRED>
<!ATTLIST diff obj_depth CDATA "-1" >
<!ATTLIST diff obj_index CDATA "-1" >
<!ATTLIST diff obj_attr_type CDATA "-1" >
<!ATTLIST diff obj_attr_index CDATA "-1" >
<!ATTLIST diff obj_attr_name CDATA "" >
<!ATTLIST diff obj_attr_newvalue CDATA "" >
<!ATTLIST diff obj_attr_oldvalue CDATA "" >
-90
View File
@@ -1,90 +0,0 @@
<!--
Copyright © 2009 CNRS
Copyright © 2009-2021 Inria. All rights reserved.
Copyright © 2009-2011 Université Bordeaux.
See COPYING in top-level directory.
This is the DTD for hwloc v2.x XMLs.
-->
<!ELEMENT topology (object+,distances2*,distances2hetero*,support*,memattr*,cpukind*)>
<!ATTLIST topology version CDATA "">
<!ELEMENT object (page_type*,info*,userdata*,object*)>
<!ATTLIST object type (Machine | Misc | Group | NUMANode | MemCache | Package | Die | L1Cache | L2Cache | L3Cache | L4Cache | L5Cache | L1iCache | L2iCache | L3iCache | Core | PU | Bridge | PCIDev | OSDev) #REQUIRED>
<!ATTLIST object subtype CDATA "" >
<!ATTLIST object os_index CDATA "-1" >
<!ATTLIST object gp_index CDATA "-1" >
<!ATTLIST object name CDATA "" >
<!ATTLIST object local_memory CDATA "0" >
<!ATTLIST object cache_size CDATA "0" >
<!ATTLIST object cache_linesize CDATA "0" >
<!ATTLIST object cache_associativity CDATA "0" >
<!ATTLIST object cache_type CDATA "0" >
<!ATTLIST object cpuset CDATA "0" >
<!ATTLIST object complete_cpuset CDATA "" >
<!ATTLIST object allowed_cpuset CDATA "" >
<!ATTLIST object nodeset CDATA "" >
<!ATTLIST object complete_nodeset CDATA "" >
<!ATTLIST object allowed_nodeset CDATA "" >
<!ATTLIST object depth CDATA "-1" >
<!ATTLIST object kind CDATA "0" >
<!ATTLIST object subkind CDATA "0" >
<!ATTLIST object dont_merge CDATA "0" >
<!ATTLIST object bridge_type CDATA "" >
<!ATTLIST object bridge_pci CDATA "" >
<!ATTLIST object pci_busid CDATA "" >
<!ATTLIST object pci_type CDATA "" >
<!ATTLIST object pci_link_speed CDATA "0." >
<!ATTLIST object osdev_type CDATA "" >
<!ELEMENT page_type EMPTY>
<!ATTLIST page_type size CDATA #REQUIRED>
<!ATTLIST page_type count CDATA #REQUIRED>
<!ELEMENT info EMPTY>
<!ATTLIST info name CDATA #REQUIRED>
<!ATTLIST info value CDATA #REQUIRED>
<!ELEMENT distances2 (indexes+,u64values+)>
<!ATTLIST distances2 type CDATA #REQUIRED>
<!ATTLIST distances2 nbobjs CDATA #REQUIRED>
<!ATTLIST distances2 indexing CDATA #REQUIRED>
<!ATTLIST distances2 kind CDATA #REQUIRED>
<!ATTLIST distances2 name CDATA "">
<!ELEMENT distances2hetero (indexes+,u64values+)>
<!ATTLIST distances2hetero nbobjs CDATA #REQUIRED>
<!ATTLIST distances2hetero kind CDATA #REQUIRED>
<!ATTLIST distances2hetero name CDATA "">
<!ELEMENT memattr (memattr_value*)>
<!ATTLIST memattr name CDATA #REQUIRED>
<!ATTLIST memattr flags CDATA #REQUIRED>
<!ELEMENT memattr_value EMPTY>
<!ATTLIST memattr_value target_obj_gp_index CDATA "">
<!ATTLIST memattr_value target_obj_type CDATA #REQUIRED>
<!ATTLIST memattr_value value CDATA #REQUIRED>
<!ATTLIST memattr_value initiator_cpuset CDATA "">
<!ATTLIST memattr_value initiator_obj_gp_index CDATA "">
<!ATTLIST memattr_value initiator_obj_type CDATA "">
<!ELEMENT indexes (#PCDATA)>
<!ATTLIST indexes length CDATA #REQUIRED>
<!ELEMENT u64values (#PCDATA)>
<!ATTLIST u64values length CDATA #REQUIRED>
<!ELEMENT userdata (#PCDATA)>
<!ATTLIST userdata name CDATA "" >
<!ATTLIST userdata length CDATA "0" >
<!ATTLIST userdata encoding CDATA "" >
<!ELEMENT support EMPTY>
<!ATTLIST support name CDATA #REQUIRED>
<!ATTLIST support value CDATA "1" >
<!ELEMENT cpukind (info*)>
<!ATTLIST cpukind cpuset CDATA "0">
<!ATTLIST cpukind forced_efficiency CDATA "-1">
-292
View File
@@ -1,292 +0,0 @@
.\" -*- nroff -*-
.\" Copyright © 2013-2022 Inria. All rights reserved.
.\" See COPYING in top-level directory.
.TH HWLOC-ANNOTATE "1" "Dec 14, 2022" "2.9.0" "hwloc"
.SH NAME
hwloc-annotate \- Modify attributes in a XML topology
.
.\" **************************
.\" Synopsis Section
.\" **************************
.SH SYNOPSIS
.B hwloc-annotate
[\fIoptions\fR]
\fI<input.xml>\fR
\fI<output.xml>\fR
-- \fI<location1>\fR \fI<location2>\fR ... --
\fI<mode>\fR
\fI<annotation>\fR
.
.B hwloc-annotate
[\fIoptions\fR]
\fI<input.xml>\fR
\fI<output.xml>\fR
\fI<location>\fR
\fI<mode>\fR
\fI<annotation>\fR
.
.PP
Note that hwloc(7) provides a detailed explanation of the hwloc system
and of valid <location> formats;
it should be read before reading this man page.
.\" **************************
.\" Options Section
.\" **************************
.SH OPTIONS
.
.TP 10
\fB\-\-ri\fR
Remove all info attributes that exist with the same name before adding the new one.
This option is only accepted in "info" mode.
If the info value is omitted, existing infos are replaced with nothing.
.TP
\fB\-\-ci\fR
Clear the existing info attributes in the target objects before annotating.
If no new annotation has to be added after clearing, \fImode\fR should be
set to \fInone\fR.
.TP
\fB\-\-cu\fR
Clear the existing userdata from the target objects.
If nothing else has to be performed after clearing, \fImode\fR should be
set to \fInone\fR.
.
.TP
\fB\-\-cd\fR
Clear the existing distances from the topology.
If nothing else has to be performed after clearing, \fImode\fR should be
set to \fInone\fR.
.TP
\fB\-\-version\fR
Report version and exit.
.TP
\fB\-h\fR \fB\-\-help\fR
Display help message and exit.
.
.\" **************************
.\" Description Section
.\" **************************
.SH DESCRIPTION
.
hwloc-annotate loads a topology from a XML file, adds some annotations,
and export the resulting topology to another XML file.
The input and output files may be the same.
.
.PP
The annotation may be string info attributes.
This is specified by the \fImode\fR:
.
.TP
.B info <name> <value>
Specifies a new string info attribute whose name is \fIname\fR and
value is \fIvalue\fR.
.TP
.B subtype <subtype>
Specifies that the subtype attribute of the object should now be \fIsubtype\fR.
If an empty string is given, the subtype is removed.
.TP
.B size <size>
Specifies the size of a cache or NUMA node.
The value may be suffixed with \fBkB\fR, \fBKiB\fR, \fBMB\fR, \fBMiB\fR,
\fBGB\fR, \fBGiB\fR, etc.
.TP
.B misc <name>
Specifies a new Misc object name.
.TP
.B memattr <name> <flags>
Register a new memory attribute whose name is \fIname\fR and
flags is \fIflags\fR.
\fIlocation\fR is ignored in this mode.
Flags may be given as numeric values or as a comma-separated list of flag names
that are passed to \fIhwloc_memattr_register()\fR.
Those names may be substrings of actual flag names as long as a single one matches.
For instance, a value of \fB1\fR (or \fBhigher\fR) means that
highest values are considered best for this attribute.
.TP
.B memattr <name> <initiator> <value>
Set the memory attribute (whose name is \fIname\fR)
from initiator \fIinitiator\fR (either an object or a CPU-set)
to target NUMA node \fIlocation\fR
to value \fIvalue\fR.
If this attribute does not require specific initiators,
\fIinitiator\fR is ignored.
Standard attribute names are \fICapacity\fR, \fILocality\fR,
\fIBandwidth\fR, and \fILatency\fR.
All existing attributes in the input topology may be listed with
$ lstopo --memattrs -i input.xml
.TP
.B cpukind <cpuset> <efficiency> <flags> [<infoname> <infovalue>]
Specifies the kind of CPU for PUs listed in the given cpuset.
\fIlocation\fR is ignored in this mode.
\fIefficiency\fR is an abstracted efficiency value that will enforce
ranking of kinds. It should be -1 if unknown.
\fIflags\fR must be 0 for now.
If \fIinfoname\fR and \fIinfovalue\fR are given and non-empty,
they are added as info attributes to this kind of CPU.
See the function hwloc_cpukinds_register() for details.
.TP
.B distances <filename> [<flags>]
Specifies new distances to be added to the topology using specifications in \fI<filename>\fR.
The optional \fIflags\fR (0 unless specified) corresponds to the flags
given to the function \fBhwloc_distances_set()\fR.
\fIlocation\fR is ignored in this mode.
The real first line of the pointed file must be a integer representing
a distances \fBkind\fR as defined in \fBhwloc/distances.h\fR.
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 \fBx*y\fR or \fBx*y*z\fR.
An optional line before all others may start with \fBname=\fR
to specify the name of the distances structure if any.
.TP
.B 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.
.TP
.B 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.
.TP
.B 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.
.TP
.B distances-transform <name> remove-obj <obj>
Remove the given object from the distances structure named <name>.
.TP
.B 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 are 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.
If <newtype> is "NULL", objects are removed from the distances structure.
.TP
.B none
No new annotation is added. This is useful when clearing existing attributes.
.
.PP
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 \fIlocation\fR (see also EXAMPLES below).
Multiple locations may be affected if they are specified between \fB--\fR.
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.
.
.PP
.B NOTE:
The existing annotations may be listed with hwloc-info.
.PP
.B 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.
.
.\" **************************
.\" Examples Section
.\" **************************
.SH EXAMPLES
.PP
hwloc-annotate's operation is best described through several examples.
.
.PP
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 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
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
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 \fBMyApplicationPerformance\fR
(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
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
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 section
.\" **************************
.SH RETURN VALUE
Upon successful execution, hwloc-annotate generates the output topology.
The return value is 0.
.
.PP
hwloc-annotate will return nonzero if any kind of error occurs, such as
(but not limited to) failure to parse the command line.
.
.\" **************************
.\" See also section
.\" **************************
.SH SEE ALSO
.
.ft R
hwloc(7), lstopo(1), hwloc-info(1)
.sp
-388
View File
@@ -1,388 +0,0 @@
.\" -*- nroff -*-
.\" Copyright © 2009-2021 Inria. All rights reserved.
.\" Copyright © 2010 Université of Bordeaux
.\" Copyright © 2009-2020 Cisco Systems, Inc. All rights reserved.
.\" See COPYING in top-level directory.
.TH HWLOC-BIND "1" "Dec 14, 2022" "2.9.0" "hwloc"
.SH NAME
hwloc-bind \- Launch a command that is bound to specific processors
and/or memory, or consult the binding of an existing program
.
.\" **************************
.\" Synopsis Section
.\" **************************
.SH SYNOPSIS
.
.B hwloc-bind
[\fItopology options\fR] [\fIoptions\fR] \fI<location1> [<location2> [...] ] [--] <command> \fR...
.
.PP
Note that hwloc(7) provides a detailed explanation of the hwloc system
and of valid <location> formats;
it should be read before reading this man page.
.\" **************************
.\" Options Section
.\" **************************
.SH TOPOLOGY OPTIONS
.
All topology options must be given before all other options.
.
.TP 10
\fB\-\-no\-smt\fR, \fB\-\-no\-smt=<N>\fR
Only keep the first PU per core before binding.
If \fI<N>\fR is specified, keep the <N>-th instead, if any.
PUs are ordered by physical index during this filtering.
.TP
\fB\-\-restrict\fR <cpuset>
Restrict the topology to the given cpuset.
.TP
\fB\-\-restrict\fR nodeset=<nodeset>
Restrict the topology to the given nodeset, unless \fB\-\-restrict\-flags\fR specifies something different.
.TP
\fB\-\-restrict\-flags\fR <flags>
Enforce 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 \fIhwloc_topology_restrict()\fR.
Those names may be substrings of actual flag names as long as a single one matches,
for instance \fBbynodeset,memless\fR.
The default is \fB0\fR (or \fBnone\fR).
.TP
\fB\-\-disallowed\fR
Include objects disallowed by administrative limitations.
.TP
\fB\-\-best\-memattr\fR <name>
Select the best NUMA node among the given memory binding set by looking
at the memory attribute given by \fI<name>\fR (or as an index).
If the memory attribute values depend on the initiator, the CPU binding
set is used as the initiator.
Standard attribute names are \fICapacity\fR, \fILocality\fR,
\fIBandwidth\fR, and \fILatency\fR.
All existing attributes in the current topology may be listed with
$ lstopo --memattrs
.TP
\fB\-\-hbm\fR
Only take high bandwidth memory nodes (Intel Xeon Phi MCDRAM)
in account when looking for NUMA nodes in the input locations.
This option must be combined with NUMA node locations,
such as \fI--hbm numa:1\fR for binding on the second HBM node.
It may also be written as \fIhbm:1\fR.
.TP
\fB\-\-no\-hbm\fR
Ignore high bandwidth memory nodes (Intel Xeon Phi MCDRAM)
when looking for NUMA nodes in the input locations.
.
.SH OPTIONS
.
All these options must be given after all topology options above.
.
.TP 10
\fB\-\-cpubind\fR
Use following arguments for CPU binding (default).
.TP
\fB\-\-membind\fR
Use following arguments for memory binding.
If \fB\-\-mempolicy\fR is not also given,
the default policy is bind.
.TP
\fB\-\-mempolicy\fR <policy>
Change the memory binding policy.
The available policies are default, firsttouch, bind, interleave
and nexttouch.
This option is only meaningful when an actual binding is also given
with \fB\-\-membind\fR.
If \fB\-\-membind\fR is given without \fB\-\-mempolicy\fR,
the default policy is bind.
.TP
\fB\-\-get\fR
Report the current bindings.
The output is an opaque bitmask that may be translated into objects with hwloc-calc
(see EXAMPLES below).
.TP
\
When a command is given, the binding is displayed before executing
the command. When no command is given, the program exits after
displaying the current binding.
.TP
\
When combined with \fB\-\-membind\fR, report the memory binding
instead of CPU binding.
.TP
\
No location may be given since no binding is performed.
.TP
\fB\-\-nodeset\fR
Report binding as a NUMA memory node set instead of a CPU set
if \-\-get was given.
This is useful for manipulating CPU-less NUMA nodes since their
cpuset is empty while their nodeset is correct.
.TP
\
Also parse input bitmasks as nodesets instead of cpusets.
.TP
\
When this option is not passed, individual input bitmasks may
still be parsed as nodesets if they are prefixed with \fInodeset=\fR.
.TP
\fB\-e\fR \fB\-\-get\-last\-cpu\-location\fR
Report the last processors where the process ran.
The output is an opaque bitmask that may be translated into objects with hwloc-calc
(see EXAMPLES below).
.TP
\
Note that the result may already be outdated when reported since
the operating system may move the process to other processors
at any time according to the binding.
.TP
\
When a command is given, the last processors is displayed before
executing the command. When no command is given, the program exits
after displaying the last processors.
.TP
\
This option cannot be combined with \fB\-\-membind\fR.
.TP
\
No location may be given since no binding is performed.
.TP
\fB\-\-single\fR
Bind on a single CPU to prevent migration.
.TP
\fB\-\-strict\fR
Require strict binding.
.TP
\fB\-\-pid\fR <pid>
Operate on pid <pid>
.TP
\fB\-\-tid\fR <tid>
Operate on thread <tid> instead of on an entire process.
The feature is only supported on Linux for thread CPU binding,
or for reporting the last processor where the thread ran if \fB\-e\fR was also passed.
.TP
\fB\-p\fR \fB\-\-physical\fR
Interpret input locations with OS/physical indexes instead of logical indexes.
This option does not apply to the output, see \fB\-\-get\fR above.
.TP
\fB\-l\fR \fB\-\-logical\fR
Interpret input locations with logical indexes instead of physical/OS indexes (default).
This option does not apply to the output, see \fB\-\-get\fR above.
.TP
\fB\-\-taskset\fR
Display CPU set strings in the format recognized by the taskset command-line
program instead of hwloc-specific CPU set string format.
This option has no impact on the format of input CPU set strings,
both formats are always accepted.
.TP
\fB\-f\fR \fB\-\-force\fR
Launch the executable even if binding failed.
.TP
\fB\-q\fR \fB\-\-quiet\fR
Hide non-fatal error messages.
It includes locations pointing to non-existing objects,
as well as failure to bind.
This is usually useful in addition to \fB\-\-force\fR.
.TP
\fB\-v\fR \fB\-\-verbose\fR
Verbose output.
.TP
\fB\-\-version\fR
Report version and exit.
.TP
\fB\-h\fR \fB\-\-help\fR
Display help message and exit.
.
.\" **************************
.\" Description Section
.\" **************************
.SH DESCRIPTION
.
hwloc-bind execs an executable (with optional command line arguments)
that is bound to the specified location (or list of locations).
Location specification is described in hwloc(7).
Upon successful execution, hwloc-bind simply sets bindings and then execs
the executable over itself.
.
.PP
If a bitmask location is given with prefix \fInodeset=\fR, then it
is considered a nodeset instead of a CPU set. See also \fB\-\-nodeset\fR.
.
.PP
If multiple locations are given, they are combined in the sense that
the binding will be wider. The process will be allowed to run on every
location inside the combination.
.
.PP
The list of input locations may be explicitly ended with "--".
.
.PP
If binding fails, or if the binding set is empty, and \fB\-\-force\fR
was not given, hwloc-bind returns with an error instead of launching
the executable.
.
.PP
.B 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-bind utility.
.
.
.\" **************************
.\" Examples Section
.\" **************************
.SH EXAMPLES
.PP
hwloc-bind's operation is best described through several examples.
More details about how locations are specified on the hwloc-bind
command line are described in hwloc(7).
.
.PP
To run the echo command on the first logical processor of the second
package:
$ hwloc-bind package:1.pu:0 -- echo hello
which is exactly equivalent to the following line as long as there is
no ambiguity between hwloc-bind option names and the executed command name:
$ hwloc-bind package:1.pu:0 echo hello
To bind the "echo" command to the first core of the second package and
the second core of the first package:
$ hwloc-bind package:1.core:0 package:0.core:1 -- echo hello
To bind on the first PU of all cores of the first package:
$ hwloc-bind package:0.core:all.pu:0 -- echo hello
$ hwloc-bind --no-smt package:0 -- echo hello
To bind on the memory node local to a PU with largest capacity:
$ hwloc-bind --best-memattr capacity --cpubind pu:23 --membind pu:23 -- echo hello
To bind memory on the first high-bandwidth memory node on Intel Xeon Phi:
$ hwloc-bind --membind hbm:0 -- echo hello
$ hwloc-bind --hbm --membind numa:0 -- echo hello
Note that binding the "echo" command to multiple processors is
probably meaningless (because "echo" is likely implemented as a
single-threaded application); these examples just serve to show what
hwloc-bind can do.
.
.PP
To run on the first three packages on the second and third nodes:
$ hwloc-bind node:1-2.package:0:3 -- echo hello
which is also equivalent to:
$ hwloc-bind node:1-2.package:0-2 -- echo hello
Note that if you attempt to bind to objects that do not exist,
hwloc-bind will not warn unless
.I -v
was specified.
To run on processor with physical index 2 in package with physical index 1:
$ hwloc-bind --physical package:1.core:2 -- echo hello
To run on odd cores within even packages:
$ hwloc-bind package:even.core:odd -- echo hello
To run on the first package, except on its second and fifth cores:
$ hwloc-bind package:0 ~package:0.core:1 ~package:0.core:4 -- echo hello
To run anywhere except on the first package:
$ hwloc-bind all ~package:0 -- echo hello
To run on a core near the network interface named eth0:
$ hwloc-bind os=eth0 -- echo hello
To run on a core near the PCI device whose bus ID is 0000:01:02.0:
$ hwloc-bind pci=0000:01:02.0 -- echo hello
To bind memory on second memory node and run on first node (when supported by the OS):
$ hwloc-bind --cpubind node:1 --membind node:0 -- echo hello
The --get option can report current bindings. This example shows
nesting hwloc-bind invocations to set a binding and then report it:
$ hwloc-bind node:1.package:2 -- hwloc-bind --get
0x00004444,0x44000000
hwloc-calc can also be used to convert cpu mask strings to
human-readable package/core/PU strings; see the description of -H in
hwloc-calc(1) for more details. The following example binds to all
the PUs in a specific core, uses the --get option to retrieve where
the process was actually bound, and then uses hwloc-calc to display
the resulting cpu mask in space-delimited list of human-readable
locations:
$ hwloc-bind package:1.core:2 -- hwloc-bind --get | hwloc-calc -H package.core.pu
Package:1.Core:2.PU:0 Package:1.Core:2.PU:1
hwloc-calc may convert this output into actual objects, either with logical or physical indexes:
$ hwloc-calc --physical -I pu `hwloc-bind --get`
26,30,34,38,42,46
$ hwloc-calc --logical -I pu `hwloc-bind --get` --sep " "
24 25 26 27 28 29
.
.PP
Locations may also be specified as a hex bit mask (typically generated
by hwloc-calc). For example:
$ hwloc-bind 0x00004444,0x44000000 -- echo hello
$ hwloc-bind `hwloc-calc node:1.package:2` -- echo hello
The current memory binding may also be reported:
$ hwloc-bind --membind node:1 --mempolicy interleave -- hwloc-bind --get --membind
0x000000f0 (interleave)
.SH HINT
If the graphics-enabled lstopo is available, use for instance
$ hwloc-bind core:2 -- lstopo --pid 0
to check what the result of your binding command actually is.
lstopo will graphically show where it is bound to by hwloc-bind.
.
.\" **************************
.\" Return value section
.\" **************************
.SH RETURN VALUE
Upon successful execution, hwloc-bind execs the command over itself.
The return value is therefore whatever the return value of the command
is.
.
.PP
hwloc-bind will return nonzero if any kind of error occurs, such as
(but not limited to): failure to parse the command line, failure to
retrieve process bindings, or lack of a command to execute.
.
.\" **************************
.\" See also section
.\" **************************
.SH SEE ALSO
.
.ft R
hwloc(7), lstopo(1), hwloc-calc(1), hwloc-distrib(1)
.sp
-468
View File
@@ -1,468 +0,0 @@
.\" -*- nroff -*-
.\" Copyright © 2010-2022 Inria. All rights reserved.
.\" Copyright © 2009-2020 Cisco Systems, Inc. All rights reserved.
.\" See COPYING in top-level directory.
.TH HWLOC-CALC "1" "Dec 14, 2022" "2.9.0" "hwloc"
.SH NAME
hwloc-calc \- Operate on cpu mask strings and objects
.
.\" **************************
.\" Synopsis Section
.\" **************************
.SH SYNOPSIS
.
.B hwloc-calc
[\fItopology options\fR] [\fIoptions\fR] \fI<location1> [<location2> [...] ]
.
.PP
Note that hwloc(7) provides a detailed explanation of the hwloc system
and of valid <location> formats;
it should be read before reading this man page.
.
.\" **************************
.\" Options Section
.\" **************************
.SH TOPOLOGY OPTIONS
.
All topology options must be given before all other options.
.
.TP 10
\fB\-\-no\-smt\fR, \fB\-\-no\-smt=<N>\fR
Only keep the first PU per core in the input locations.
If \fI<N>\fR is specified, keep the <N>-th instead, if any.
PUs are ordered by physical index during this filtering.
.TP
\fB\-\-cpukind\fR <n>
\fB\-\-cpukind\fR <infoname>=<infovalue>
Only keep PUs whose CPU kind match.
Either a single CPU kind is specified as an index,
or the info name/value keypair will select matching kinds.
When specified by index, it corresponds to hwloc ranking of CPU kinds
which returns energy-efficient cores first, and high-performance
power-hungry cores last.
The full list of CPU kinds may be seen with \fIlstopo --cpukinds\fR.
.TP
\fB\-\-restrict\fR <cpuset>
Restrict the topology to the given cpuset.
.TP
\fB\-\-restrict\fR nodeset=<nodeset>
Restrict the topology to the given nodeset, unless \fB\-\-restrict\-flags\fR specifies something different.
.TP
\fB\-\-restrict\-flags\fR <flags>
Enforce 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 \fIhwloc_topology_restrict()\fR.
Those names may be substrings of actual flag names as long as a single one matches,
for instance \fBbynodeset,memless\fR.
The default is \fB0\fR (or \fBnone\fR).
.TP
\fB\-\-disallowed\fR
Include objects disallowed by administrative limitations.
.TP
\fB\-i\fR <path>, \fB\-\-input\fR <path>
Read the topology from <path> instead of discovering the topology of the local machine.
If <path> is a file and XML support has been compiled in hwloc,
it may be a XML file exported by a previous hwloc program.
If <path> is "\-", the standard input may be used as a 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.
.TP
\fB\-i\fR <specification>, \fB\-\-input\fR <specification>
Simulate 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.
.TP
\fB\-\-if\fR <format>, \fB\-\-input\-format\fR <format>
Enforce the input in the given format, among \fBxml\fR, \fBfsroot\fR,
\fBcpuid\fR and \fBsynthetic\fR.
.
.SH OPTIONS
.
All these options must be given after all topology options above.
.
.TP 10
\fB\-p\fR \fB\-\-physical\fR
Use OS/physical indexes instead of logical indexes for both input and output.
.TP
\fB\-l\fR \fB\-\-logical\fR
Use logical indexes instead of physical/OS indexes for both input and output (default).
.TP
\fB\-\-pi\fR \fB\-\-physical\-input\fR
Use OS/physical indexes instead of logical indexes for input.
.TP
\fB\-\-li\fR \fB\-\-logical\-input\fR
Use logical indexes instead of physical/OS indexes for input (default).
.TP
\fB\-\-po\fR \fB\-\-physical\-output\fR
Use OS/physical indexes instead of logical indexes for output.
.TP
\fB\-\-lo\fR \fB\-\-logical\-output\fR
Use logical indexes instead of physical/OS indexes for output (default, except for cpusets which are always physical).
.TP
\fB\-n\fR \fB\-\-nodeset\fR
Interpret both input and output sets as nodesets instead of CPU sets.
See \fB\-\-nodeset\-output\fR and \fB\-\-nodeset\-input\fR below for details.
.TP
\fB\-\-no\fR \fB\-\-nodeset\-output\fR
Report nodesets instead of CPU sets.
This output is more precise than the default CPU set output when memory
locality matters because it properly describes CPU-less NUMA nodes,
as well as NUMA-nodes that are local to multiple CPUs.
.TP
\fB\-\-ni\fR \fB\-\-nodeset\-input\fR
Interpret input sets as nodesets instead of CPU sets.
.TP
\fB\-N \-\-number\-of <type|depth>\fR
Report the number of objects of the given type or depth that intersect the CPU set.
This is convenient for finding how many cores, NUMA nodes or PUs are available
in a machine.
When combined with \fB\-\-nodeset\fR or \fB\-\-nodeset-output\fR,
the nodeset is considered instead of the CPU set for finding matching objects.
This is useful when reporting the output as a number or set of NUMA nodes.
If an OS device subtype such as \fIgpu\fR is given instead of \fIosdev\fR,
only the os devices of that subtype will be counted.
.TP
\fB\-I \-\-intersect <type|depth>\fR
Find the list of objects of the given type or depth that intersect the CPU set and
report the comma-separated list of their indexes instead of the cpu mask string.
This may be used for determining the list of objects above or below the input
objects.
When combined with \fB\-\-physical\fR, the list is convenient to pass to external
tools such as taskset or numactl \fB\-\-physcpubind\fR or \fB\-\-membind\fR.
This is different from \-\-largest since the latter requires that all reported
objects are strictly included inside the input objects.
When combined with \fB\-\-nodeset\fR or \fB\-\-nodeset-output\fR,
the nodeset is considered instead of the CPU set for finding matching objects.
This is useful when reporting the output as a number or set of NUMA nodes.
If an OS device subtype such as \fIgpu\fR is given instead of \fIosdev\fR,
only the os devices of that subtype will be returned.
.TP
\fB\-H \-\-hierarchical <type1>.<type2>...\fR
Find the list of objects of type <type2> that intersect the CPU set and
report the space-separated list of their hierarchical indexes with respect
to <type1>, <type2>, etc.
For instance, if \fIpackage.core\fR is given, the output would be
\fIPackage:1.Core:2 Package:2.Core:3\fR if the input contains the third
core of the second package and the fourth core of the third package.
Only normal CPU-side object types should be used.
NUMA nodes may be used but they may cause redundancy in the output
on heterogeneous memory platform. For instance, on a platform with both
DRAM and HBM memory on a package, the first core will be considered both
as first core of first NUMA node (DRAM) and
as first core of second NUMA node (HBM).
.TP
\fB\-\-largest\fR
Report (in a human readable format) the list of largest objects which exactly
include all input objects (by looking at their CPU sets).
None of these output objects intersect each other, and the sum of them is
exactly equivalent to the input. No largest object is included in the input
This is different from \-\-intersect where reported objects may not be
strictly included in the input.
.TP
\fB\-\-local\-memory\fR
Report the list of NUMA nodes that are local to the input objects.
This option is similar to \fB\-I numa\fR but the way nodes are selected
is different:
The selection performed by \fB\-\-local\-memory\fR may be precisely
configured with \fB\-\-local\-memory\-flags\fR,
while \fB\-I numa\fR just selects all nodes that are somehow local to
any of the input objects.
.TP
\fB\-\-local\-memory\-flags\fR
Change 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 \fIhwloc_get_local_numanode_objs()\fR.
Those names may be substrings of actual flag names as long as a single one matches.
The default is \fB3\fR (or \fBsmaller,larger\fR)
which means NUMA nodes are displayed
if their locality either contains or is contained
in the locality of the given object.
This option enables \fB\-\-local\-memory\fR.
.TP
\fB\-\-best\-memattr\fR <name>
Enable the listing of local memory nodes with \fB\-\-local\-memory\fR,
but only display the local node that has the best value for the memory
attribute given by \fI<name>\fR (or as an index).
If the memory attribute values depend on the initiator, the hwloc-calc
input objects are used as the initiator.
Standard attribute names are \fICapacity\fR, \fILocality\fR,
\fIBandwidth\fR, and \fILatency\fR.
All existing attributes in the current topology may be listed with
$ lstopo --memattrs
.TP
\fB\-\-sep <sep>\fR
Change the field separator in the output.
By default, a space is used to separate output objects
(for instance when \fB\-\-hierarchical\fR or \fB\-\-largest\fR is given)
while a comma is used to separate indexes
(for instance when \fB\-\-intersect\fR is given).
.TP
\fB\-\-single\fR
Singlify the output to a single CPU.
.TP
\fB\-\-taskset\fR
Display CPU set strings in the format recognized by the taskset command-line
program instead of hwloc-specific CPU set string format.
This option has no impact on the format of input CPU set strings,
both formats are always accepted.
.TP
\fB\-q\fR \fB\-\-quiet\fR
Hide non-fatal error messages.
It mostly includes locations pointing to non-existing objects.
.TP
\fB\-v\fR \fB\-\-verbose\fR
Verbose output.
.TP
\fB\-\-version\fR
Report version and exit.
.TP
\fB\-h\fR \fB\-\-help\fR
Display help message and exit.
.
.\" **************************
.\" Description Section
.\" **************************
.SH DESCRIPTION
.
hwloc-calc generates and manipulates CPU mask strings or objects.
Both input and output may be either objects (with physical or logical
indexes), CPU lists (with physical or logical indexes), or CPU mask strings
(always physically indexed).
Input location specification is described in hwloc(7).
.
.PP
If objects or CPU mask strings are given on the command-line,
they are combined and a single output is printed.
If no object or CPU mask strings are given on the command-line,
the program will read the standard input.
It will combine multiple objects or CPU mask strings that are
given on the same line of the standard input line with spaces
as separators.
Different input lines will be processed separately.
.
.PP
Command-line arguments and options are processed in order.
First topology configuration options should be given.
Then, for instance, changing the type of input indexes
with \fB\-\-li\fR or changing the input topology with \fB\-i\fR
only affects the processing the following arguments.
.
.PP
.B 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.
.
.
.\" **************************
.\" Examples Section
.\" **************************
.SH EXAMPLES
.PP
hwloc-calc's operation is best described through several examples.
.
.PP
To display the (physical) CPU mask corresponding to the second package:
$ hwloc-calc package:1
0x000000f0
To display the (physical) CPU mask corresponding to the third pacakge, excluding
its even numbered logical processors:
$ hwloc-calc package:2 ~PU:even
0x00000c00
To convert a cpu mask to human-readable output, the -H option can be
used to emit a space-delimited list of locations:
$ echo 0x000000f0 | hwloc-calc -H package.core
Package:1.Core1 Package:1.Core:1 Package:1.Core:2 Package:1.Core:3
To use some other character (e.g., a comma) instead of spaces in
output, use the --sep option:
$ echo 0x000000f0 | hwloc-calc -H package.core --sep ,
Package:1.Core1,Package:1.Core:1,Package:1.Core:2,Package:1.Core:3
To combine two (physical) CPU masks:
$ hwloc-calc 0x0000ffff 0xff000000
0xff00ffff
To display the list of logical numbers of processors included in the second
package:
$ hwloc-calc --intersect PU package:1
4,5,6,7
To bind GNU OpenMP threads logically over the whole machine, we need to use
physical number output instead:
$ export GOMP_CPU_AFFINITY=`hwloc-calc --physical-output --intersect PU all`
$ echo $GOMP_CPU_AFFINITY
0,4,1,5,2,6,3,7
To display the list of NUMA nodes, by physical indexes, that intersect a given (physical) CPU mask:
$ hwloc-calc --physical --intersect NUMAnode 0xf0f0f0f0
0,2
To find how many cores are in the second CPU kind
(those cores are likely higher-performance and more power-hungry than cores of the first kind):
$ hwloc-calc --cpukind 1 -N core all
4
To display the list of NUMA nodes, by physical indexes,
whose locality is exactly equal to a Package:
$ hwloc-calc --local-memory-flags 0 pack:1
4,7
To display the best-capacity NUMA node, by physical indexe,
whose locality is exactly equal to a Package:
$ hwloc-calc --local-memory-flags 0 --best-memattr capacity pack:1
4
Converting object logical indexes (default) from/to physical/OS indexes
may be performed with \fB--intersect\fR combined with either \fB--physical-output\fR
(logical to physical conversion) or \fB--physical-input\fR (physical to logical):
$ hwloc-calc --physical-output PU:2 --intersect PU
3
$ hwloc-calc --physical-input PU:3 --intersect PU
2
One should add \fB--nodeset\fR when converting indexes of memory objects
to make sure a single NUMA node index is returned on platforms
with heterogeneous memory:
$ hwloc-calc --nodeset --physical-output node:2 --intersect node
3
$ hwloc-calc --nodeset --physical-input node:3 --intersect node
2
To display the set of CPUs near network interface eth0:
$ hwloc-calc os=eth0
0x00005555
To display the indexes of packages near PCI device whose bus ID is 0000:01:02.0:
$ hwloc-calc pci=0000:01:02.0 --intersect Package
1
To display the list of per-package cores that intersect the input:
$ hwloc-calc 0x00003c00 --hierarchical package.core
Package:2.Core:1 Package:3.Core:0
To display the (physical) CPU mask of the entire topology except the third package:
$ hwloc-calc all ~package:3
0x0000f0ff
To combine both physical and logical indexes as input:
$ hwloc-calc PU:2 --physical-input PU:3
0x0000000c
To synthetize a set of cores into largest objects on a 2-node 2-package 2-core machine:
$ hwloc-calc core:0 --largest
Core:0
$ hwloc-calc core:0-1 --largest
Package:0
$ hwloc-calc core:4-7 --largest
NUMANode:1
$ hwloc-calc core:2-6 --largest
Package:1 Package:2 Core:6
$ hwloc-calc pack:2 --largest
Package:2
$ hwloc-calc package:2-3 --largest
NUMANode:1
To get the set of first threads of all cores:
$ hwloc-calc core:all.pu:0
$ hwloc-calc --no-smt all
This can also be very useful in order to make GNU OpenMP use exactly one thread
per core, and in logical core order:
$ export OMP_NUM_THREADS=`hwloc-calc --number-of core all`
$ echo $OMP_NUM_THREADS
4
$ export GOMP_CPU_AFFINITY=`hwloc-calc --physical-output --intersect PU --no-smt all`
$ echo $GOMP_CPU_AFFINITY
0,2,1,3
To export bitmask in a format that is acceptable by the resctrl Linux subsystem
(for configuring cache partitioning, etc), apply a sed regexp to the output of hwloc-calc:
$ hwloc-calc pack:all.core:7-9.pu:0
0x00000380,,0x00000380 <this format cannot be given to resctrl>
$ hwloc-calc pack:all.core:7-9.pu:0 | sed -e 's/0x//g' -e 's/,,/,0,/g' -e 's/,,/,0,/g'
00000380,0,00000380
# echo 00000380,0,00000380 > /sys/fs/resctrl/test/cpus
# cat /sys/fs/resctrl/test/cpus
00000000,00000380,00000000,00000380 <the modified bitmask was corrected parsed by resctrl>
OS devices may also be filtered by subtype. In this example, there are
8 OS devices in the system, 4 of them are near NUMA node #1, and only
2 of these are CoProcessors:
$ utils/hwloc/hwloc-calc -I osdev all
0,1,2,3,4,5,6,7,8
$ utils/hwloc/hwloc-calc -I osdev node:1
5,6,7,8
$ utils/hwloc/hwloc-calc -I coproc node:1
7,8
.
.\" **************************
.\" Return value section
.\" **************************
.SH RETURN VALUE
Upon successful execution, hwloc-calc displays the (physical) CPU mask string,
(physical or logical) object list, or (physical or logical) object number list.
The return value is 0.
.
.
.PP
hwloc-calc will return nonzero if any kind of error occurs, such as
(but not limited to): failure to parse the command line.
.
.\" **************************
.\" See also section
.\" **************************
.SH SEE ALSO
.
.ft R
hwloc(7), lstopo(1), hwloc-info(1)
.sp
@@ -1,91 +0,0 @@
.\" -*- nroff -*-
.\" Copyright © 2013-2021 Inria. All rights reserved.
.\" See COPYING in top-level directory.
.TH HWLOC-COMPRESS-DIR "1" "Dec 14, 2022" "2.9.0" "hwloc"
.SH NAME
hwloc-compress-dir \- Compress a directory of XML topologies
.
.\" **************************
.\" Synopsis Section
.\" **************************
.SH SYNOPSIS
.B hwloc-compress-dir
[\fIoptions\fR]
<inputdir>
<outputdir>
\fR
.
.\" **************************
.\" Options Section
.\" **************************
.SH OPTIONS
.TP
\fB\-R \-\-reverse\fR
Uncompress a previously compressed directory.
.TP
\fB\-v \-\-verbose\fR
Display verbose messages.
.TP
\fB\-\-version\fR
Report version and exit.
.TP
\fB\-h\fR \fB\-\-help\fR
Display help message and exit.
.
.\" **************************
.\" Description Section
.\" **************************
.SH DESCRIPTION
.
hwloc-compress-dir takes an input directory containing XML exports
and tries to compress it by computing topology diffs between them
(with the hwloc-diff program).
Each file is copied in the output directory either as a diff if it
could be compressed, or as its original entire file otherwise.
.
.PP
hwloc-compress-dir may recompress a directory that was previously
compressed. All input files that are already in the output directory,
either compressed or not, are ignored. New input files are compressed
as much as possible as usual.
.
.PP
For each file of the directory, the output filename is
the same as the original if not compressed,
otherwise its extension is changed to \fB.diff.xml\fR.
.
.PP
Compressed files are based on another non-compressed topology.
Its name is stored in the \fBrefname\fR topology diff attribute.
.
.PP
The generated output diff files may be used with hwloc-patch
just like any file generated by hwloc-diff.
.
.\" **************************
.\" Examples Section
.\" **************************
.SH EXAMPLES
.PP
To compress the input files from directory in into directory out:
$ hwloc-compress-dir in out
.
.\" **************************
.\" Return value section
.\" **************************
.SH RETURN VALUE
Upon successful execution, hwloc-compress-dir returns 0.
.
.PP
hwloc-compress-dir will return nonzero if any kind of error occurs,
such as (but not limited to) failure to parse the command line.
.
.\" **************************
.\" See also section
.\" **************************
.SH SEE ALSO
.
.ft R
hwloc(7), lstopo(1), hwloc-diff(1), hwloc-patch(1)
.sp
-129
View File
@@ -1,129 +0,0 @@
.\" -*- nroff -*-
.\" Copyright © 2013-2018 Inria. All rights reserved.
.\" See COPYING in top-level directory.
.TH HWLOC-DIFF "1" "Dec 14, 2022" "2.9.0" "hwloc"
.SH NAME
hwloc-diff \- Compute differences between two XML topologies
.
.\" **************************
.\" Synopsis Section
.\" **************************
.SH SYNOPSIS
.
.PP
.B hwloc-diff
[\fIoptions\fR]
\fI<input1.xml>\fR
\fI<input2.xml>\fR
.PP
.B hwloc-diff
[\fIoptions\fR]
\fI<input1.xml>\fR
\fI<input2.xml>\fR
\fI<output.xml>\fR
.
.\" **************************
.\" Options Section
.\" **************************
.SH OPTIONS
.
.TP 10
\fB\-\-refname\fR <name>
Use <name> as the identifier for the reference topology
in the output XML difference.
It is meant to tell which topology should be used when applying
the resulting difference.
hwloc-patch may use that name to automatically load the relevant
reference topology XML.
By default, <input1.xml> is used without its full path.
.TP
\fB\-\-version\fR
Report version and exit.
.TP
\fB\-h\fR \fB\-\-help\fR
Display help message and exit.
.
.\" **************************
.\" Description Section
.\" **************************
.SH DESCRIPTION
.
hwloc-diff computes the difference between two XML topologies
and stores the result into <output.xml> if any, or dumps it
to stdout otherwise.
.
.PP
The output difference may later be applied to another topology
with hwloc-patch.
.
.PP
hwloc-compress-dir may be used for computing the diffs between
all XML files in a directory.
.
.PP
.B NOTE:
If some application-specific userdata were been exported to the input XMLs,
they will be ignored and discarded from the output because hwloc has no way
to understand and compare them.
.
.PP
.B 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-diff utility.
.
.\" **************************
.\" Examples Section
.\" **************************
.SH EXAMPLES
.PP
hwloc-diff's operation is best described through several examples.
.
.PP
Compute the difference between two XML topologies and output it to stdout:
$ hwloc-diff fourmi023.xml fourmi024.xml
Found 11 differences, exporting to stdout
<?xml version="1.0" encoding="UTF-8"?>
...
Output the difference to file diff.xml instead:
$ hwloc-diff fourmi023.xml fourmi024.xml diff.xml
Found 11 differences, exporting to diff.xml
When the difference is too complex to be represented:
$ hwloc-diff fourmi023.xml avakas-frontend1.xml
Found 1 differences, including 1 too complex ones.
Cannot export differences to stdout
Directly compute the difference between two topologies and apply it
to another one:
$ hwloc-diff fourmi023.xml fourmi024.xml | hwloc-patch fourmi025.xml -
.
.\" **************************
.\" Return value section
.\" **************************
.SH RETURN VALUE
Upon successful execution, hwloc-diff outputs the difference.
The return value is 0.
.
.PP
If the difference is too complex to be represented, an error is returned
and the output is not generated.
.
.PP
hwloc-diff also returns nonzero if any kind of error occurs, such as
(but not limited to) failure to parse the command line.
.
.\" **************************
.\" See also section
.\" **************************
.SH SEE ALSO
.
.ft R
hwloc(7), lstopo(1), hwloc-patch(1), hwloc-compress-dir(1)
.sp
-198
View File
@@ -1,198 +0,0 @@
.\" -*- nroff -*-
.\" Copyright © 2010-2022 Inria. All rights reserved.
.\" Copyright © 2009-2010 Cisco Systems, Inc. All rights reserved.
.\" See COPYING in top-level directory.
.TH HWLOC-DISTRIB "1" "Dec 14, 2022" "2.9.0" "hwloc"
.SH NAME
hwloc-distrib \- Build a number of cpu masks distributed on the system
.
.\" **************************
.\" Synopsis Section
.\" **************************
.SH SYNOPSIS
.B hwloc-distrib
[\fIoptions\fR] \fI<integer>\fR
.
.\" **************************
.\" Options Section
.\" **************************
.SH OPTIONS
.TP
\fB\-\-single\fR
Singlify each output to a single CPU.
.TP
\fB\-\-taskset\fR
Show CPU set strings in the format recognized by the taskset command-line
program instead of hwloc-specific CPU set string format.
.TP
\fB\-v\fR \fB\-\-verbose\fR
Verbose messages.
.TP
\fB\-i\fR <path>, \fB\-\-input\fR <path>
Read the topology from <path> instead of discovering the topology of the local machine.
If <path> is a file and XML support has been compiled in hwloc,
it may be a XML file exported by a previous hwloc program.
If <path> is "\-", the standard input may be used as a 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.
.TP
\fB\-i\fR <specification>, \fB\-\-input\fR <specification>
Simulate 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.
.TP
\fB\-\-if\fR <format>, \fB\-\-input\-format\fR <format>
Enforce the input in the given format, among \fBxml\fR, \fBfsroot\fR,
\fBcpuid\fR and \fBsynthetic\fR.
.TP
\fB\-\-ignore\fR <type>
Ignore all objects of type <type> in the topology.
.TP
\fB\-\-from\fR <type>
Distribute starting from objects of the given type instead of from
the top of the topology hierarchy, i.e. ignoring the structure given by objects
above.
<type> cannot be among NUMANode, I/O or Misc types.
.TP
\fB\-\-to\fR <type>
Distribute down to objects of the given type instead of down to the bottom of
the topology hierarchy, i.e. ignoring the structure given by objects below.
This may be useful if some latitude is desired for the binding, e.g. just bind
several processes to each package without specifying a single core for each
of them.
<type> cannot be among NUMANode, I/O or Misc types.
.TP
\fB\-\-at\fR <type>
Distribute among objects of the given type. This is equivalent to specifying
both \fB\-\-from\fR and \fB\-\-to\fR at the same time.
.TP
\fB\-\-reverse\fR
Distribute by starting with the last objects first,
and singlify CPU sets by keeping the last bit (instead of the first bit).
.TP
\fB\-\-restrict\fR <cpuset>
Restrict the topology to the given cpuset.
.TP
\fB\-\-restrict\fR nodeset=<nodeset>
Restrict the topology to the given nodeset, unless \fB\-\-restrict\-flags\fR specifies something different.
.TP
\fB\-\-restrict\-flags\fR <flags>
Enforce 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 \fIhwloc_topology_restrict()\fR.
Those names may be substrings of actual flag names as long as a single one matches,
for instance \fBbynodeset,memless\fR.
The default is \fB0\fR (or \fBnone\fR).
.TP
\fB\-\-disallowed\fR
Include objects disallowed by administrative limitations.
.TP
\fB\-\-version\fR
Report version and exit.
.TP
\fB\-h\fR \fB\-\-help\fR
Display help message and exit.
.
.\" **************************
.\" Description Section
.\" **************************
.SH DESCRIPTION
.
hwloc-distrib generates a series of CPU masks corresponding to a distribution of
a given number of elements over the topology of the machine. The distribution
is done recursively from the top of the hierarchy (or from the level specified
by option \fB\-\-from\fR) down to the bottom of the hierarchy (or down to the
level specified by option \fB\-\-to\fR, or until only one element remains),
splitting the number of elements at each encountered hierarchy level not ignored
by options \fB\-\-ignore\fR.
.
.PP
This can e.g. be used to distribute a set of processes hierarchically according
to the topology of a machine. These masks can be used with hwloc-bind(1).
.
.PP
.B 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-bind utility.
.
.\" **************************
.\" Examples Section
.\" **************************
.SH EXAMPLES
.PP
hwloc-distrib's operation is best described through several examples.
.
.PP
If 4 processes have to be distributed across a machine, their CPU masks
may be obtained with:
$ hwloc-distrib 4
0x0000000f
0x00000f00
0x000000f0
0x0000f000
To distribute only among the second package, the topology should be restricted:
$ hwloc-distrib --restrict $(hwloc-calc package:1) 4
0x00000010
0x00000020
0x00000040
0x00000080
To get a single processor of each CPU masks (prevent migration in case
of binding)
$ hwloc-distrib 4 --single
0x00000001
0x00000100
0x00000010
0x00001000
Each output line may be converted independently with hwloc-calc:
$ hwloc-distrib 4 --single | hwloc-calc --taskset
0x1
0x100
0x10
0x1000
To convert the output into a list of processors that may be passed to
dplace -c inside a mpirun command line:
$ hwloc-distrib 4 --single | xargs hwloc-calc --pulist
0,8,4,16
.
.
.\" **************************
.\" Return value section
.\" **************************
.SH RETURN VALUE
Upon successful execution, hwloc-distrib displays one or more CPU mask
strings. The return value is 0.
.
.
.PP
hwloc-distrib will return nonzero if any kind of error occurs, such as
(but not limited to) failure to parse the command line.
.
.\" **************************
.\" See also section
.\" **************************
.SH SEE ALSO
.
.ft R
hwloc(7)
.sp
@@ -1,110 +0,0 @@
.\" -*- nroff -*-
.\" Copyright © 2015-2021 Inria. All rights reserved.
.\" See COPYING in top-level directory.
.TH HWLOC-GATHER-CPUID "1" "Dec 14, 2022" "2.9.0" "hwloc"
.SH NAME
hwloc-gather-cpuid \- Dumps the relevant x86 cpuid values
for later (possibly offline) usage
.
.\" **************************
.\" Synopsis Section
.\" **************************
.SH SYNOPSIS
.
.B hwloc-gather-cpuid [\fIoptions\fR] [\fI<outdir>\fR]
.
.\" **************************
.\" Options Section
.\" **************************
.SH OPTIONS
.
.TP
\fB\-c <idx>
Only gather cpuid values for logical processor whose OS/physical index
is <idx>.
.TP
\fB\-s\fR \fB\-\-silent\fR
Do not show verbose messages.
.TP
\fB\-\-version\fR
Report version and exit.
.TP
\fB\-h\fR \fB\-\-help\fR
Display help message and exit.
.
.\" **************************
.\" Description Section
.\" **************************
.SH DESCRIPTION
.
\fBhwloc-gather-cpuid\fR dumps all the relevant x86 cpuid values into
subdirectory \fIcpuid\fR of current directory,
or in \fB<outdir>\fR if specified.
.
.PP
These files can be used later to explore the machine topology offline,
for instance by setting the environment variable \fIHWLOC_CPUID_PATH\fR
to the directory containing all output files,
and by forcing the x86 backend with \fIHWLOC_COMPONENTS=x86,stop\fR.
.
.PP
The directory contents may also be submitted to hwloc developers
to debug issues remotely.
.
.PP
If \fB-\fR is used as <outdir>, the output is dumped to the standard
output, but a unique logical processor must have been given with \fB-c\fR.
.
.PP
\fBhwloc-gather-cpuid\fR is a x86 specific tool, it cannot be used
on other platforms.
.
.PP
.B NOTE:
\fBhwloc-gather-cpuid\fR gathers many hardware details about the platform.
Output files should not be posted on public lists or websites
unless it is clear that they contain no sensitive information.
.
.PP
.B NOTE:
The output of \fBhwloc-gather-cpuid\fR is included in the tarball
saved by \fBhwloc-gather-topology\fR on Linux/x86.
.
.PP
.B NOTE:
It is highly recommended that you read the hwloc(7) overview page
before reading this man page.
.
.\" **************************
.\" Examples Section
.\" **************************
.SH EXAMPLES
.PP
To store cpuid information of all logical processors of the current machine:
$ hwloc-gather-cpuid
Gathering in directory ./cpuid ...
Gathering CPUID of PU P#0 in path ./hwloc-x86-cpuid/pu0 ...
Gathering CPUID of PU P#1 in path ./hwloc-x86-cpuid/pu1 ...
Gathering CPUID of PU P#2 in path ./hwloc-x86-cpuid/pu2 ...
Gathering CPUID of PU P#3 in path ./hwloc-x86-cpuid/pu3 ...
Summary written to ./cpuid/hwloc-cpuid-info
.
.\" **************************
.\" Return value section
.\" **************************
.SH RETURN VALUE
Upon successful execution, \fBhwloc-gather-cpuid\fR will exit with the code 0.
.
.PP
\fBhwloc-gather-cpuid\fR will return nonzero exit status if any kind of error occurs,
such as (but not limited to) failure to create the output files.
.
.\" **************************
.\" See also section
.\" **************************
.SH SEE ALSO
.
.ft R
hwloc(7), hwloc-gather-topology(1), lstopo(1)
.sp
-277
View File
@@ -1,277 +0,0 @@
.\" -*- nroff -*-
.\" Copyright © 2009-2022 Inria. All rights reserved.
.\" Copyright © 2009-2010 Université of Bordeaux
.\" Copyright © 2009-2010 Cisco Systems, Inc. All rights reserved.
.\" See COPYING in top-level directory.
.TH HWLOC-INFO "1" "Dec 14, 2022" "2.9.0" "hwloc"
.SH NAME
hwloc-info \- Show some information about some objects or about a topology or about support features
.
.\" **************************
.\" Synopsis Section
.\" **************************
.SH SYNOPSIS
.
.PP
.B hwloc-info
[ \fIoptions \fR]...
\fI<object>\fR...
.PP
.B hwloc-info
[ \fIoptions \fR]...
.
.PP
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.
.\" **************************
.\" Options Section
.\" **************************
.SH OPTIONS
.
.TP
\fB\-\-objects\fR
Report information specific objects.
This is the default if some objects are given on the command-line.
.TP
\fB\-\-topology\fR
Report a summary of the topology instead of about some specific objects.
This is the default if no object is given on the command-line.
.TP
\fB\-\-support\fR
Report the features that are supported by hwloc on the topology.
The features are those available through the \fBhwloc_topology_get_support()\fR function.
This is useful for verifying which CPU or memory binding options are supported
by the current hwloc installation.
.TP
\fB\-i\fR <path>, \fB\-\-input\fR <path>
Read the topology from <path> instead of discovering the topology of the local machine.
If <path> is a file and XML support has been compiled in hwloc,
it may be a XML file exported by a previous hwloc program.
If <path> is "\-", the standard input may be used as a 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.
.TP
\fB\-i\fR <specification>, \fB\-\-input\fR <specification>
Simulate 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.
.TP
\fB\-\-if\fR <format>, \fB\-\-input\-format\fR <format>
Enforce the input in the given format, among \fBxml\fR, \fBfsroot\fR,
\fBcpuid\fR and \fBsynthetic\fR.
.TP
\fB\-v\fR \fB\-\-verbose\fR
Include additional detail.
.TP
\fB\-s\fR \fB\-\-silent\fR
Reduce the amount of details to show.
A single summary line per object is displayed.
.TP
\fB\-\-ancestors\fR
Display information about the object as well as
about all its ancestors up to the root of the topology.
.TP
\fB\-\-ancestor\fR <type>
Only display the object ancestors that match the given type.
.TP
\fB\-\-children\fR
Display information about the object children.
.TP
\fB\-\-descendants\fR <type>
Display information about the object descendants that match the given type.
.TP
\fB\-\-local\-memory\fR
Display information about the NUMA nodes that are local to the given object.
.TP
\fB\-\-local\-memory\-flags\fR
Change 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 \fIhwloc_get_local_numanode_objs()\fR.
Those names may be substrings of actual flag names as long as a single one matches.
The default is \fB3\fR (or \fBsmaller,larger\fR)
which means NUMA nodes are displayed
if their locality either contains or is contained
in the locality of the given object.
This option enables \fB\-\-local\-memory\fR.
.TP
\fB\-\-best\-memattr\fR <name>
Enable the listing local memory nodes with \fB\-\-local\-memory\fR,
but only display the local node that has the best value for the memory
attribute given by \fI<name>\fR (or as an index).
If the memory attribute values depend on the initiator, the object given
to hwloc-info is used as the initiator.
.TP
\fB\-n\fR
When outputting object information, prefix 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 \fB\-\-ancestor\fR 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).
.TP
\fB\-\-disallowed\fR
Include objects disallowed by administrative limitations.
.TP
\fB\-\-restrict\fR <cpuset>
Restrict the topology to the given cpuset.
.TP
\fB\-\-restrict\fR nodeset=<nodeset>
Restrict the topology to the given nodeset, unless \fB\-\-restrict\-flags\fR specifies something different.
.TP
\fB\-\-restrict\fR binding
Restrict the topology to the current process binding.
This option requires the use of the actual current machine topology
(or any other topology with \fB\-\-thissystem\fR or with
HWLOC_THISSYSTEM set to 1 in the environment).
.TP
\fB\-\-restrict\-flags\fR <flags>
Enforce 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 \fIhwloc_topology_restrict()\fR.
Those names may be substrings of actual flag names as long as a single one matches,
for instance \fBbynodeset,memless\fR.
The default is \fB0\fR (or \fBnone\fR).
.TP
\fB\-\-filter\fR <type>:<kind>, \fB\-\-filter\fR <type>
Filter 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.
.TP
\fB\-\-no\-icaches\fR
Do not show Instruction caches, only Data and Unified caches are considered.
This is identical to \fB-\-filter icache:none\fR.
.TP
\fB\-\-no\-io\fB
Do not show any I/O device or bridge.
This is identical to \fB\-\-filter io:none\fR.
By default, common devices (GPUs, NICs, block devices, ...) and
interesting bridges are shown.
.TP
\fB\-\-no\-bridges\fB
Do not show any I/O bridge except hostbridges.
This is identical to \fB\-\-filter bridge:none\fR.
By default, common devices (GPUs, NICs, block devices, ...) and
interesting bridges are shown.
.TP
\fB\-\-whole\-io\fB
Show all I/O devices and bridges.
This is identical to \fB\-\-filter io:all\fR.
By default, only common devices (GPUs, NICs, block devices, ...) and
interesting bridges are shown.
.TP
\fB\-\-thissystem\fR
Assume that the selected backend provides the topology for the
system on which we are running.
This is useful when using \fB\-\-restrict\fR binding and loading
a custom topology such as an XML file.
.TP
\fB\-\-pid\fR <pid>
Detect topology as seen by process <pid>, i.e. as if process <pid> did the
discovery itself.
Note that this can for instance change the set of allowed processors.
Also show this process current CPU binding by marking the corresponding
PUs (in Green in the graphical output, see the COLORS section below,
or by appending \fI(binding)\fR to the verbose text output).
If 0 is given as pid, the current binding for the lstopo process will be shown.
.TP
\fB\-p\fR \fB\-\-physical\fR
Use OS/physical indexes instead of logical indexes for input.
.TP
\fB\-l\fR \fB\-\-logical\fR
Use logical indexes instead of physical/OS indexes for input (default).
.TP
\fB\-\-version\fR
Report version and exit.
.TP
\fB\-h\fR \fB\-\-help\fR
Display help message and exit.
.
.\" **************************
.\" Description Section
.\" **************************
.SH DESCRIPTION
.
hwloc-info displays information about the specified object.
It is intended to be used with tools such as grep for filtering
certain attribute lines.
When no object is specified, or when \fB\-\-topology\fR is passed,
hwloc-info prints a summary of the topology.
When \fB\-\-support\fR is passed, hwloc-info lists the supported
features for the topology.
.
.PP
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.
.
.PP
.B 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.
.
.\" **************************
.\" Examples Section
.\" **************************
.SH EXAMPLES
.PP
To display information about each package:
$ hwloc-info package:all
Package L#0
logical index = 0
...
To display information about the core whose physical index is 2:
$ hwloc-info -p core:2
Core L#1
logical index = 1
os index = 2
...
To list the NUMA nodes that are local 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
...
To show the best-bandwidth node among NUMA nodes local to a PU:
$ hwloc-info --local-memory --best-memattr bandwidth pu:25
NUMANode L#7 = local memory #1 of PU L#25
type = NUMANode
...
.
.\" **************************
.\" See also section
.\" **************************
.SH SEE ALSO
.
.ft R
hwloc(7), lstopo(1), hwloc-calc(1), hwloc-bind(1), hwloc-ps(1)
.sp
-874
View File
@@ -1,874 +0,0 @@
.\" -*- nroff -*-
.\" Copyright © 2009-2022 Inria. All rights reserved.
.\" Copyright © 2009-2010 Université of Bordeaux
.\" Copyright © 2009-2010 Cisco Systems, Inc. All rights reserved.
.\" Copyright © 2020 Hewlett Packard Enterprise. All rights reserved.
.\" See COPYING in top-level directory.
.TH LSTOPO "1" "Dec 14, 2022" "2.9.0" "hwloc"
.SH NAME
lstopo, lstopo-no-graphics, hwloc-ls \- Show the topology of the system
.
.\" **************************
.\" Synopsis Section
.\" **************************
.SH SYNOPSIS
.
.B lstopo
[ \fIoptions \fR]... [ \fIfilename \fR]
.
.PP
.B lstopo-no-graphics
[ \fIoptions \fR]... [ \fIfilename \fR]
.
.PP
.B hwloc-ls
[ \fIoptions \fR]... [ \fIfilename \fR]
.
.PP
Note that hwloc(7) provides a detailed explanation of the hwloc system; it
should be read before reading this man page
.
.\" **************************
.\" Options Section
.\" **************************
.SH OPTIONS
.
.TP
\fB\-\-of\fR <format>, \fB\-\-output\-format\fR <format>
Enforce the output in the given format.
See the OUTPUT FORMATS section below.
.TP
\fB\-i\fR <path>, \fB\-\-input\fR <path>
Read the topology from <path> instead of discovering the topology of the local machine.
If <path> is a file and XML support has been compiled in hwloc,
it may be a XML file exported by a previous hwloc program.
If <path> is "\-", the standard input may be used as a 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.
.TP
\fB\-i\fR <specification>, \fB\-\-input\fR <specification>
Simulate 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.
.TP
\fB\-\-if\fR <format>, \fB\-\-input\-format\fR <format>
Enforce the input in the given format, among \fBxml\fR, \fBfsroot\fR,
\fBcpuid\fR and \fBsynthetic\fR.
.TP
\fB\-\-export\-xml\-flags\fR <flags>
Enforce flags when exporting to the XML format.
Flags may be given as numeric values or as a comma-separated list of flag names
that are passed to \fIhwloc_topology_export_xml()\fR.
Those names may be substrings of actual flag names as long as a single one matches.
A value of \fB1\fR (or \fBv1\fR) reverts to the format of hwloc v1.x.
The default is \fB0\fR (or \fBnone\fR).
.TP
\fB\-\-export\-synthetic\-flags\fR <flags>
Enforce flags when exporting to the synthetic format.
Flags may be given as numeric values or as a comma-separated list of flag names
that are passed to \fIhwloc_topology_export_synthetic()\fR.
Those names may be substrings of actual flag names as long as a single one matches.
A value of \fB2\fR (or \fBno_attr\fR) reverts to the format of hwloc v1.9.
A value of \fB3\fR (or \fBno_ext,no_attr\fR) reverts to the original minimalistic format (before v1.9).
The default is \fB0\fR (or \fBnone\fR).
.TP
\fB\-v\fR \fB\-\-verbose\fR
Include additional detail.
The hwloc-info tool may be used to display even more information
about specific objects.
.TP
\fB\-s\fR \fB\-\-silent\fR
Reduce the amount of details to show.
.TP
\fB\-\-distances\fR
Only display distance matrices.
.TP
\fB\-\-distances-transform\fR <links|merge-switch-ports|transitive-closure>
Try applying a transformation to distances structures before displaying them.
See hwloc_distances_transform() for details.
More transformations may be applied using hwloc-annotate(1)
(and it may save their output to XML).
.TP
\fB\-\-memattrs\fR
Only display memory attributes.
All of them are displayed (while the default textual output selects
memory attribute details depending on the verbosity level).
.TP
\fB\-\-cpukinds\fR
Only display CPU kinds.
CPU kinds are displayed in order, starting from the most energy efficient
ones up to the rather higher performance and power hungry ones.
.TP
\fB\-\-windows\-processor\-groups\fR
On Windows, only show information about processor groups.
All of them are displayed, while the default verbose output
only shows them if there are more than one.
.TP
\fB\-f\fR \fB\-\-force\fR
If the destination file already exists, overwrite it.
.TP
\fB\-l\fR \fB\-\-logical\fR
Display hwloc logical indexes of all objects, with prefix "L#".
.
By default, both logical and physical/OS indexes are displayed for PUs and NUMA nodes,
logical only for cores, dies and packages, and no index for other types.
.TP
\fB\-p\fR \fB\-\-physical\fR
Display OS/physical indexes of all objects, with prefix "P#".
.
By default, both logical and physical/OS indexes are displayed for PUs and NUMA nodes,
logical only for cores, dies and packages, and no index for other types.
.TP
\fB\-\-logical\-index\-prefix\fR <prefix>
Replace " L#" with the given prefix for logical indexes.
.TP
\fB\-\-os\-index\-prefix\fR <prefix>
Replace " P#" with the given prefix for physical/OS indexes.
.TP
\fB\-c\fR \fB\-\-cpuset\fR
Display the cpuset of each object.
.TP
\fB\-C\fR \fB\-\-cpuset\-only\fR
Only display the cpuset of each object; do not display anything else
about the object.
.TP
\fB\-\-taskset\fR
Show CPU set strings in the format recognized by the taskset command-line
program instead of hwloc-specific CPU set string format.
This option should be combined with \fB\-\-cpuset\fR or \fB\-\-cpuset\-only\fR,
otherwise it will imply \fB\-\-cpuset\fR.
.TP
\fB\-\-only\fR <type>
Only show objects of the given type in the textual output.
.TP
\fB\-\-filter\fR <type>:<kind>, \fB\-\-filter\fR <type>
Filter 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), only important objects are kept.
See hwloc_topology_set_type_filter() for more details.
hwloc supports filtering any type except PUs and NUMA nodes.
lstopo also offers PU and NUMA node filtering by hiding them in the graphical and textual outputs,
but any object included in them (for instance Misc) will be hidden as well.
Note that PUs and NUMA nodes may not be ignored in the XML output.
Note also that the top-level object type cannot be ignored (usually Machine or System).
.TP
\fB\-\-ignore\fR <type>
This is the old way to specify \fB-\-filter <type>:none\fR.
.TP
\fB\-\-no\-smt\fR
Ignore PUs.
This is identical to \fB-\-filter PU:none\fR.
.TP
\fB\-\-no\-caches\fR
Do not show caches.
This is identical to \fB-\-filter cache:none\fR.
.TP
\fB\-\-no\-useless\-caches\fR
This is identical to \fB-\-filter cache:structure\fR.
.TP
\fB\-\-no\-icaches\fR
This is identical to \fB-\-filter icache:none\fR.
.TP
\fB\-\-disallowed\fR
Include objects disallowed by administrative limitations (e.g Cgroups on Linux).
Offline PUs and NUMA nodes are still ignored.
.TP
\fB\-\-allow\fR <all|local|0xff|nodeset=0xf0>
Include objects disallowed by administrative limitations (implies \fB\-\-disallowed\fR)
and also change the set of allowed ones.
If \fBlocal\fR is given, only objects available to the current process are allowed
(default behavior when loading from the native operating system backend).
It may be useful if the topology was created by another process (with different
administrative restrictions such as Linux Cgroups) and loaded here loaded from XML
or synthetic.
This case implies \fB\-\-thissystem\fR.
If \fBall\fR, all objects are allowed.
If a bitmap is given as a hexadecimal string, it is used as the set of allowed PUs.
If a bitmap is given after prefix \fBnodeset=\fR, it is the set of allowed NUMA nodes.
.TP
\fB\-\-flags\fR <flags>
Enforce topology flags.
Flags may be given as numeric values or as a comma-separated list of flag names
that are passed to \fIhwloc_topology_set_flags()\fR.
Those names may be substrings of actual flag names as long as a single one matches,
for instance \fBdisallowed,thissystem_allowed\fR.
The default is \fB8\fR (or \fBimport\fR).
.TP
\fB\-\-merge\fR
Do not show levels that do not have a hierarchical impact.
This sets HWLOC_TYPE_FILTER_KEEP_STRUCTURE for all object types.
This is identical to \fB\-\-filter all:structure\fR.
.TP
\fB\-\-no\-factorize\fR \fB\-\-no\-factorize\fR=<type>
Never factorize identical objects in the graphical output.
If an object type is given, only factorizing of these objects is disabled.
This only applies to normal CPU-side objects, it is independent from PCI collapsing.
.TP
\fB\-\-factorize\fR \fB\-\-factorize\fR=[<type>,]<N>[,<L>[,<F>]
Factorize identical children in the graphical output (enabled by default).
If <N> is specified (4 by default), factorizing only occurs when there are strictly
more than N identical children.
If <L> and <F> are specified, they set the numbers of first and last children to keep
after factorizing.
If an object type is given, only factorizing of these objects is configured.
This only applies to normal CPU-side object, it is independent from PCI collapsing.
.TP
\fB\-\-no\-collapse\fR
Do not collapse identical PCI devices.
By default, identical sibling PCI devices (such as many virtual functions
inside a single physical device) are collapsed.
.TP
\fB\-\-no\-cpukinds\fR
Do not show different kinds of CPUs in the graphical output.
By default, when supported, different types of lines, thickness
and bold font may be used to display PU boxes of different kinds.
.TP
\fB\-\-restrict\fR <cpuset>
Restrict the topology to the given cpuset.
.TP
\fB\-\-restrict\fR nodeset=<nodeset>
Restrict the topology to the given nodeset, unless --restrict-flags specifies something different.
.TP
\fB\-\-restrict\fR binding
Restrict the topology to the current process binding.
This option requires the use of the actual current machine topology
(or any other topology with \fB\-\-thissystem\fR or with
HWLOC_THISSYSTEM set to 1 in the environment).
.TP
\fB\-\-restrict\-flags\fR <flags>
Enforce 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 \fIhwloc_topology_restrict()\fR.
Those names may be substrings of actual flag names as long as a single one matches,
for instance \fBbynodeset,memless\fR.
The default is \fB0\fR (or \fBnone\fR).
.TP
\fB\-\-no\-io\fB
Do not show any I/O device or bridge.
This is identical to \fB\-\-filter io:none\fR.
By default, common devices (GPUs, NICs, block devices, ...) and
interesting bridges/switches are shown.
.TP
\fB\-\-no\-bridges\fB
Do not show any I/O bridge except hostbridges.
This is identical to \fB\-\-filter bridge:none\fR.
By default, common devices (GPUs, NICs, block devices, ...) and
interesting bridges/switches are shown.
.TP
\fB\-\-whole\-io\fB
Show all I/O devices and bridges.
This is identical to \fB\-\-filter io:all\fR.
By default, only common devices (GPUs, NICs, block devices, ...) and
interesting bridges/switches are shown.
.TP
\fB\-\-thissystem\fR
Assume that the selected backend provides the topology for the
system on which we are running.
This is useful when loading a custom topology such as an XML file
and using \fB\-\-restrict binding\fR or \fB\-\-allow all\fR.
.TP
\fB\-\-pid\fR <pid>
Detect topology as seen by process <pid>, i.e. as if process <pid> did the
discovery itself.
Note that this can for instance change the set of allowed processors.
Also show this process current CPU and Memory binding by marking the corresponding
PUs and NUMA nodes (in Green in the graphical output, see the COLORS section below,
or by appending \fI(binding)\fR to the verbose text output).
If 0 is given as pid, the current binding for the lstopo process will be shown.
.TP
\fB\-\-ps\fR \fB\-\-top\fR
Show existing processes as misc objects in the output. To avoid uselessly
cluttering the output, only processes that are restricted to some part of the
machine are shown. On Linux, kernel threads are not shown.
If many processes appear, the output may become hard to read anyway,
making the hwloc-ps program more practical.
.TP
\fB\-\-children\-order\fR <order>
Change the order of the different kinds of children with respect to
their parent in the graphical output.
\fI<order>\fR may be a comma-separated list of keywords among:
\fImemory:above\fR displays memory children above other children
(and above the parent if it is a cache).
PUs are therefore below their local NUMA nodes, like hwloc 1.x did.
\fIio:right\fR and \fImisc:right\fR place I/O or Misc children
on the right of CPU children.
\fIio:below\fR and \fImisc:below\fR place I/O or Misc children
below CPU children.
\fIplain\fR places everything not specified together with
normal CPU children.
If only \fIplain\fR is specified, lstopo displays the topology
in a basic manner that strictly matches the actual tree:
Memory, I/O and Misc children are listed below their parent just like any other child.
PUs are therefore on the side of their local NUMA nodes,
below a common ancestor.
This output may result in strange layouts since the size of Memory,
CPU and I/O children may be very different, causing the placement
algorithm to poorly arrange them in rows.
The default order is \fImemory:above,io:right,misc:right\fR which means
Memory children are above CPU children while I/O and Misc are together
on the right.
Up to hwloc 2.5, the default was rather to \fImemory:above,plain\fR.
Additionally, \fIio:right\fR, \fIio:below\fR, \fImisc:right\fR
and \fImisc:below\fR may be suffixed with
\fI:horiz\fR, \fI:vert\fR or \fI:rect\fR to force the horizontal,
vertical or rectangular layout of children inside these sections.
See also the GRAPHICAL OUTPUT and LAYOUT sections below.
.TP
\fB\-\-fontsize\fR <size>
Set the size of text font in the graphical output.
The default is 10.
Boxes are scaled according to the text size.
The \fILSTOPO_TEXT_XSCALE\fR environment variable may be used
to further scale the width of boxes (its default value is 1.0).
The \fB\-\-fontsize\fR option is ignored in the ASCII backend.
.TP
\fB\-\-gridsize\fR <size>
Set the margin between elements in the graphical output.
The default is 7. It was 10 prior to hwloc 2.1.
This option is ignored in the ASCII backend.
.TP
\fB\-\-linespacing\fR <size>
Set the spacing between lines of text in the graphical output.
The default is 4.
The option was included in \fB\-\-gridsize\fR prior to hwloc 2.1 (and its default was 10).
This option is ignored in the ASCII backend.
.TP
\fB\-\-thickness\fR <size>
Set the thickness of lines and boxes in the graphical output.
The default is 1.
This option is ignored in the ASCII backend.
.TP
\fB\-\-horiz\fR, \fB\-\-horiz\fR=<type1,...>
Force a horizontal graphical layout instead of nearly 4/3 ratio in the graphical output.
If a comma-separated list of object types is given, the layout only
applies to the corresponding \fIcontainer\fR objects.
Ignored for bridges since their children are always vertically aligned.
.TP
\fB\-\-vert\fR, \fB\-\-vert\fR=<type1,...>
Force a vertical graphical layout instead of nearly 4/3 ratio in the graphical output.
If a comma-separated list of object types is given, the layout only
applies to the corresponding \fIcontainer\fR objects.
.TP
\fB\-\-rect\fR, \fB\-\-rect\fR=<type1,...>
Force a rectangular graphical layout with nearly 4/3 ratio in the graphical output.
If a comma-separated list of object types is given, the layout only
applies to the corresponding \fIcontainer\fR objects.
Ignored for bridges since their children are always vertically aligned.
.TP
\fB\-\-no\-text\fR, \fB\-\-no\-text\fR=<type1,...>
Do not display any text in boxes in the graphical output.
If a comma-separated list of object types is given, text is disabled for the corresponding objects.
This is mostly useful for removing text from Group objects.
.TP
\fB\-\-text\fR, \fB\-\-text\fR=<type1,...>
Display text in boxes in the graphical output (default).
If a comma-separated list of object types is given, text is reenabled for the corresponding objects
(if it was previously disabled with \fB\-\-no\-text\fR).
.TP
\fB\-\-no\-index\fR, \fB\-\-no\-index\fR=<type1,...>
Do not show object indexes in the graphical output.
If a comma-separated list of object types is given, indexes are disabled for the corresponding objects.
.TP
\fB\-\-index\fR, \fB\-\-index=\fR<type1,...>
Show object indexes in the graphical output (default).
If a comma-separated list of object types is given, indexes are reenabled for the corresponding objects
(if they were previously disabled with \fB\-\-no\-index\fR).
.TP
\fB\-\-no\-attrs\fR, \fB\-\-no\-attrs\fR=<type1,...>
Do not show object attributes (such as memory size, cache size, PCI bus ID, PCI link speed, etc.)
in the graphical output.
If a comma-separated list of object types is given, attributes are disabled for the corresponding objects.
.TP
\fB\-\-attrs\fR, \fB\-\-attrs=\fR<type1,...>
Show object attributes (such as memory size, cache size, PCI bus ID, PCI link speed, etc.)
in the graphical output (default).
If a comma-separated list of object types is given, attributes are reenabled for the corresponding objects
(if they were previously disabled with \fB\-\-no\-attrs\fR).
.TP
\fB\-\-no\-legend\fR
Remove all text legend lines at the bottom of the graphical output.
.TP
\fB\-\-no\-default\-legend\fR
Remove default text legend lines at the bottom of the graphical output.
User-added legend lines with \fB\-\-append\-legend\fB or the "lstopoLegend" info
are still displayed if any.
.TP
\fB\-\-append\-legend\fR <line>
Append the line of text to the bottom of the legend in the graphical output.
If adding multiple lines, each line should be given separately by
passing this option multiple times.
Additional legend lines may also be specified inside the topology using the
"lstopoLegend" info attributes on the topology root object.
.TP
\fB\-\-grey\fR, \fB\-\-greyscale\fR
Use greyscale instead of colors in the graphical output.
.TP
\fB\-\-palette\fR <grey|greyscale|defaut|colors|white|none>
Change the color palette.
Passing \fIgrey\fR or \fIgreyscale\fR is identical to passing \fB\-\-grey\fR or \fB\-\-greyscale\fR.
Passing \fIwhite\fR or \fInone\fR uses white instead of colors for all box backgrounds.
Passing \fIdefault\fR or \fIcolors\fR reverts back to the default color palette.
.TP
\fB\-\-palette\fR type=#rrggbb
Replace the color of the given box type with the given 3x8bit hexadecimal RGB combination (e.g. \fI#ff0000\fR is red).
Existing types are \fImachine\fR, \fIgroup\fR, \fIpackage\fR, \fIgroup_in_package\fR, \fIdie\fR, \fIcore\fR, \fIpu\fR, \fInumanode\fR, \fImemories\fR (box containing multiple memory children), \fIcache\fR, \fIpcidev\fR, \fIosdev\fR, \fIbridge\fR, and \fImisc\fR.
See also CUSTOM COLOR below for customizing individual objects.
.TP
\fB\-\-binding\-color\fR <none|#rrggbb>
Do not colorize PUs and NUMA nodes according to the binding in the graphical output.
Or change the color to the given 3x8bit hexadecimal RGB combination (e.g. \fI#ff0000\fR is red).
.TP
\fB\-\-disallowed\-color\fR <none|#rrggbb>
Do not colorize disallowed PUs and NUMA nodes in the graphical output.
Or change the color to the given 3x8bit hexadecimal RGB combination (e.g. \fI#00ff00\fR is green).
.TP
\fB\-\-top\-color\fR <none|#rrggbb>
Do not colorize task objects in the graphical output when \-\-top is given.
Or change the color to the given 3x8bit hexadecimal RGB combination (e.g. \fI#0000ff\fR is blue).
.TP
\fB\-\-version\fR
Report version and exit.
.TP
\fB\-h\fR \fB\-\-help\fR
Display help message and exit.
.
.\" --shmem-output-addr is undocumented on purpose
.
.\" **************************
.\" Description Section
.\" **************************
.SH DESCRIPTION
.
lstopo and lstopo-no-graphics are capable of displaying a topological map of
the system in a variety of different output formats. The only difference
between lstopo and lstopo-no-graphics is that graphical outputs are only
supported by lstopo, to reduce dependencies on external libraries.
hwloc-ls is identical to lstopo-no-graphics.
.
.PP
The filename specified directly implies the output format that will be
used; see the OUTPUT FORMATS section, below. Output formats that
support color will indicate specific characteristics about individual
CPUs by their color; see the COLORS section, below.
.
.\" **************************
.\" Output Formats Section
.\" **************************
.SH OUTPUT FORMATS
.
.PP
By default, if no output filename is specific, the output is sent
to a graphical window if possible in the current environment
(DISPLAY environment variable set on Unix, etc.).
Otherwise, a text summary is displayed in the console.
The console is also used when the program runs from a terminal
and the output is redirected to a pipe or file.
These default behaviors may be changed by passing \fB\-\-of console\fR
to force console mode or \fB\-\-of window\fR for graphical window.
.
.PP
The filename on the command line usually determines the format of the output.
There are a few filenames that indicate specific output formats and
devices (e.g., a filename of "-" will output a text summary to
stdout), but most filenames indicate the desired output format by
their suffix (e.g., "topo.png" will output a PNG-format file).
.PP
The format of the output may also be changed with "\-\-of".
For instance, "\-\-of pdf" will generate a PDF-format file on the standard
output, while "\-\-of fig toto" will output a Xfig-format file named "toto".
.
.PP
The list of currently supported formats is given below. Any of them may
be used with "\-\-of" or as a filename suffix.
.TP
.B default
Send the output to a window or to the console depending on the environment.
.
.TP
.B window
Send the output to a graphical window.
.
.TP
.B console
Send a text summary to stdout.
Binding or unallowed processors are only annotated in this mode
if verbose; see the COLORS section, below.
.
.TP
.B ascii
Output an ASCII art representation of the map
(formerly called \fBtxt\fR).
If outputting to stdout and if colors are supported on the terminal,
the output will be colorized.
.
.TP
\fBtikz\fR or \fBtex\fR
Output a LaTeX tikzpicture representation of the map that can be
compiled with a LaTeX compiler.
.
.TP
.B fig
Output a representation of the map that can be loaded in Xfig.
.
.TP
.B svg
Output a SVG representation of the map,
using Cairo (by default, if supported)
or a native SVG backend (fallback, always supported).
See \fBcairosvg\fR and \fBnativesvg\fR below.
.
.TP
\fBcairosvg\fR or \fBsvg(cairo)\fR
If lstopo was compiled with the proper support,
output a SVG representation of the map using Cairo.
.
.TP
\fBnativesvg\fR or \fBsvg(native)\fR
Output a SVG representation of the map using the native SVG backend.
It may be less pretty than the Cairo output, but it is always supported,
and SVG objects have attributes for identifying and manipulating them.
See dynamic_SVG_example.html for an example.
.
.TP
.B pdf
If lstopo was compiled with the proper
support, lstopo outputs a PDF representation of the map.
.
.TP
.B ps
If lstopo was compiled with the proper
support, lstopo outputs a Postscript representation of the map.
.
.TP
.B png
If lstopo was compiled with the proper
support, lstopo outputs a PNG representation of the map.
.
.TP
.B synthetic
If the topology is symmetric
(which requires that the root object has its symmetric_subtree field set),
lstopo outputs a synthetic description string.
This output may be reused as an input synthetic topology
description later.
See also the Synthetic topologies section in the documentation.
Note that Misc and I/O devices are ignored during this export.
.
.TP
.B xml
If lstopo was compiled with the proper
support, lstopo outputs an XML representation of the map.
It may be reused later, even on another machine, with lstopo \-\-input,
the HWLOC_XMLFILE environment variable, or the hwloc_topology_set_xml()
function.
.PP
The following special names may be used:
.TP
.B \-
Send a text summary to stdout.
.
.TP
.B /dev/stdout
Send a text summary to stdout. It is effectively the same as
specifying "\-".
.
.TP
.B \-.<format>
If the entire filename is "\-.<format>", lstopo behaves as if
"\-\-of <format> -" was given, which means a file of the given format
is sent to the standard output.
.PP
See the output of "lstopo \-\-help" for a specific list of what
graphical output formats are supported in your hwloc installation.
.
.\" **************************
.\" Graphical Section
.\" **************************
.
.SH GRAPHICAL OUTPUT
The graphical output is made of nested boxes representing
the inclusion of objects in the hierarchy of resources.
Usually a Machine box contains one or several Package boxes,
that contain multiple Core boxes, with one or several PUs each.
.SS Caches
Caches are displayed in a slightly different manner because
they do not actually include computing resources such as cores.
For instance, a L2 Cache shared by a pair of Cores is drawn
as a Cache box on top of two Core boxes
(instead of having Core boxes inside the Cache box).
.SS NUMA nodes and Memory-side Caches
By default, NUMA nodes boxes are drawn on top of their local
computing resources.
For instance, a processor Package containing one NUMA node
and four Cores is displayed as a Package box containing
the NUMA node box above four Core boxes.
If a NUMA node is local to the L3 Cache, the NUMA node is displayed
above that Cache box.
All this specific drawing strategy for memory objects may be disabled
by passing command-line option \fB\-\-children\-order plain\fR.
If multiple NUMA nodes are attached to the same parent object,
they are displayed inside an additional unnamed memory box.
If some Memory-side Caches exist in front of some NUMA nodes,
they are drawn as boxes immediately above them.
.SS PCI bridges, PCI devices and OS devices
The PCI hierarchy is not drawn as a set of included boxes but rather
as a tree of bridges (that may actually be switches) with links between them.
The tree starts with a small square on the left for the
hostbridge or root complex.
It ends with PCI device boxes on the right.
Intermediate PCI bridges/switches may appear as additional small
squares in the middle.
PCI devices on the right of the tree are boxes containing
their PCI bus ID (such as 00:02.3).
They may also contain sub-boxes for OS device objects
such as a network interface \fIeth0\fR or a CUDA GPU \fIcuda0\fR.
When there is a single link (horizontal line) on the right of a
PCI bridge, it means that a single device or bridge is connected
on the secondary PCI bus behind that bridge.
When there is a vertical line, it means that multiple devices
and/or bridges are connected to the same secondary PCI bus.
The datarate of a PCI link may be written (in GB/s) right below
its drawn line (if the operating system and/or libraries are able
to report that information).
This datarate is the currently configured speed of the entire PCI link
(sum of the bandwidth of all PCI lanes in that link).
It may change during execution since some devices are able to
slow their PCI links down when idle.
.
.\" **************************
.\" Layout Section
.\" **************************
.SH LAYOUT
In its graphical output, lstopo uses simple rectangular heuristics
to try to achieve a 4/3 ratio between width and height.
Although the hierarchy of resources is properly reflected,
the exact physical organization (NUMA distances, rings,
complete graphs, etc.) is currently ignored.
The layout of a level may be changed with \fB\-\-vert\fR, \fB\-\-horiz\fR,
and \fB\-\-rect\fR to force a parent object to arrange its children
in vertical, horizontal or rectangular manners respectively.
The position of Memory, I/O and Misc children with respect to other
children objects may be changed using \fB\-\-children\-order\fR.
This effectivement divides children into multiple sections.
The layout of children is first computed inside each section,
before sections are placed inside (or below) the parent box.
The vertical/horizontal/rectangular layout of these additional
sections may also be configured through \fB\-\-children\-order\fR.
.
.\" **************************
.\" Colors Section
.\" **************************
.SH COLORS
Individual CPUs and NUMA nodes are colored in the graphical output
formats to indicate different characteristics:
.TP
Green
The topology is reported as seen by a specific process (see \fB\-\-pid\fR),
and the given CPU or NUMA node is in this process CPU or Memory binding mask.
.TP
White
The CPU or NUMA node is in the allowed set (see below).
If the topology is reported as seen by a specific process (see \fB\-\-pid\fR),
the object is also not in this process binding mask.
.TP
Red
The CPU or NUMA node is not in the allowed set (see below).
.
.PP
The "allowed set" is the set of CPUs or NUMA nodes to which the current process is
allowed to bind. The allowed set is usually either inherited from the
parent process or set by administrative qpolicies on the system. Linux
cpusets are one example of limiting the allowed set for a process and
its children to be less than the full set of CPUs or NUMA nodes on the system.
.PP
Different processes may therefore have different CPUs or NUMA nodes in the allowed
set. Hence, invoking lstopo in different contexts and/or as different
users may display different colors for the same individual CPUs (e.g.,
running lstopo in one context may show a specific CPU as red, but
running lstopo in a different context may show the same CPU as white).
.PP
Some lstopo output modes, e.g. the console mode (default non-graphical output),
do not support colors at all.
The console mode displays the above characteristics by appending text
to each PU line if verbose messages are enabled.
.
.SH CUSTOM COLORS
The colors of different kinds of boxes may be configured with \fB\-\-palette\fR.
The color of each object in the graphical output may also be enforced by
specifying a "lstopoStyle" info attribute in that object.
Its value should be a semi-colon separated list of "<attribute>=#rrggbb"
where rr, gg and bb are the RGB components of a color,
each between 0 and 255, in hexadecimal (00 to ff).
.
<attribute> may be
.TP
\fBBackground\fR
Sets the background color of the main object box.
.TP
\fBText\fR
Sets the color of the text showing the object name, type, index, etc.
.TP
\fBText2\fB
Sets the color of the additional text near the object,
for instance the link speed behind a PCI bridge.
.PP
The "lstopoStyle" info may be added to a temporarily-saved XML topologies
with hwloc-annotate, or with hwloc_obj_add_info().
.
For instance, to display all core objects in blue (with white names):
lstopo save.xml
hwloc-annotate save.xml save.xml core:all info lstopoStyle "Background=#0000ff;Text=#ffffff"
lstopo -i save.xml
.
.\" **************************
.\" Examples Section
.\" **************************
.SH EXAMPLES
.
To display the machine topology in textual mode:
lstopo-no-graphics
To display the machine topology in ascii-art mode:
lstopo-no-graphics -.ascii
To display in graphical mode (assuming that the DISPLAY environment
variable is set to a relevant value):
lstopo
To export the topology to a PNG file:
lstopo file.png
To export an XML file on a machine and later display the corresponding
graphical output on another machine:
machine1$ lstopo file.xml
<transfer file.xml from machine1 to machine2>
machine2$ lstopo --input file.xml
To save the current machine topology to XML and later reload it faster
while still considering it as the current machine:
$ lstopo file.xml
<...>
$ lstopo --input file.xml --thissystem
To restrict an XML topology to only physical processors 0, 1, 4 and 5:
lstopo --input file.xml --restrict 0x33 newfile.xml
To restrict an XML topology to only numa node whose logical index is 1:
lstopo --input file.xml --restrict $(hwloc-calc --input file.xml node:1) newfile.xml
To display a summary of the topology:
lstopo -s
To get more details about the topology:
lstopo -v
To only show cores:
lstopo --only core
To show cpusets:
lstopo --cpuset
To only show the cpusets of package:
lstopo --only package --cpuset-only
Simulate a fake hierarchy; this example shows with 2 NUMA nodes of 2
processor units:
lstopo --input "node:2 2"
To count the number of logical processors in the system
lstopo --only pu | wc -l
To append the kernel release and version to the graphical legend:
lstopo --append-legend "Kernel release: $(uname -r)" --append-legend "Kernel version: $(uname -v)"
.
.\" **************************
.\" Notes Section
.\" **************************
.SH NOTES
.
lstopo displays memory and cache sizes with units such as
\fBkB\fR (1 kilobyte = 1000 bytes) or \fBGB\fR (1 gigabyte = 1000*1000*1000 bytes)
while it actually means
\fBKiB\fR (1 kibibyte = 1024 bytes) or \fBGiB\fR (1 gibibytes = 1024*1024*1024 bytes) .
.
.\" **************************
.\" See also section
.\" **************************
.SH SEE ALSO
.
.ft R
hwloc(7), hwloc-info(1), hwloc-bind(1), hwloc-annotate(1), hwloc-ps(1), hwloc-gather-topology(1), hwloc-gather-cpuid(1)
.sp
-123
View File
@@ -1,123 +0,0 @@
.\" -*- nroff -*-
.\" Copyright © 2013-2018 Inria. All rights reserved.
.\" See COPYING in top-level directory.
.TH HWLOC-PATCH "1" "Dec 14, 2022" "2.9.0" "hwloc"
.SH NAME
hwloc-patch \- Apply a topology difference to an existing XML topology
.
.\" **************************
.\" Synopsis Section
.\" **************************
.SH SYNOPSIS
.
.PP
.B hwloc-patch
[\fIoptions\fR]
\fI[<topology.xml> | refname]\fR
\fI[<diff.xml> | -]\fR
\fI<output.xml>\fR
.PP
.B hwloc-patch
[\fIoptions\fR]
\fI[<topology.xml> | refname]\fR
\fI[<diff.xml> | -]\fR
.
.\" **************************
.\" Options Section
.\" **************************
.SH OPTIONS
.
.TP 10
\fB\-R \-\-reverse\fR
Reverse the sense the difference file.
.TP
\fB\-\-version\fR
Report version and exit.
.TP
\fB\-h\fR \fB\-\-help\fR
Display help message and exit.
.
.\" **************************
.\" Description Section
.\" **************************
.SH DESCRIPTION
.
hwloc-patch loads the difference between two topologies from a XML file
(or from the standard input) and applies it to an
existing topology, generating a new, modified one.
.
.PP
The XML difference may have been computed earlier with hwloc-diff
or hwloc-compress-dir.
.
.PP
If <output.xml> is given, the new, modified topology is stored in that
new file. Otherwise, <topology.xml> is modified in place.
.
.PP
If \fBrefname\fR is given instead of <topology.xml>, the input topology filename
is automatically guessed by reading the refname field of the XML diff file.
By default hwloc-diff generates XML diffs with the right reference topology
filename (without any path prefix).
.
.PP
If \fB-\fR is given instead of <diff.xml>, the topology difference is read from
the standard input.
.
.PP
.B NOTE:
If some application-specific userdata were been exported to the input XMLs,
they will be ignored and discarded from the output because hwloc has no way
to understand and patch them.
.
.PP
.B 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-patch utility.
.
.\" **************************
.\" Examples Section
.\" **************************
.SH EXAMPLES
.PP
hwloc-patch's operation is best described through several examples.
.
.PP
Apply a XML topology difference file to an existing topology:
$ hwloc-patch fourmi023.xml diff.xml fourmi023-new.xml
Apply a XML topology difference file whole refname field contains the right input topology:
$ hwloc-patch refname diff.xml fourmi023-new.xml
Apply a XML topology from the standard intput:
$ cat diff.xml | hwloc-patch fourmi023.xml - fourmi023-new.xml
Directly compute the difference between two topologies and apply it
to another one, in place:
$ hwloc-diff fourmi023.xml fourmi024.xml | hwloc-patch fourmi025.xml -
.
.\" **************************
.\" Return value section
.\" **************************
.SH RETURN VALUE
Upon successful execution, hwloc-patch outputs the modified topology.
The return value is 0.
.
.PP
hwloc-patch also returns nonzero if any kind of error occurs, such as
(but not limited to) failure to parse the command line.
.
.\" **************************
.\" See also section
.\" **************************
.SH SEE ALSO
.
.ft R
hwloc(7), lstopo(1), hwloc-diff(1), hwloc-compress-dir(1)
.sp
@@ -1,874 +0,0 @@
.\" -*- nroff -*-
.\" Copyright © 2009-2022 Inria. All rights reserved.
.\" Copyright © 2009-2010 Université of Bordeaux
.\" Copyright © 2009-2010 Cisco Systems, Inc. All rights reserved.
.\" Copyright © 2020 Hewlett Packard Enterprise. All rights reserved.
.\" See COPYING in top-level directory.
.TH LSTOPO "1" "Dec 14, 2022" "2.9.0" "hwloc"
.SH NAME
lstopo, lstopo-no-graphics, hwloc-ls \- Show the topology of the system
.
.\" **************************
.\" Synopsis Section
.\" **************************
.SH SYNOPSIS
.
.B lstopo
[ \fIoptions \fR]... [ \fIfilename \fR]
.
.PP
.B lstopo-no-graphics
[ \fIoptions \fR]... [ \fIfilename \fR]
.
.PP
.B hwloc-ls
[ \fIoptions \fR]... [ \fIfilename \fR]
.
.PP
Note that hwloc(7) provides a detailed explanation of the hwloc system; it
should be read before reading this man page
.
.\" **************************
.\" Options Section
.\" **************************
.SH OPTIONS
.
.TP
\fB\-\-of\fR <format>, \fB\-\-output\-format\fR <format>
Enforce the output in the given format.
See the OUTPUT FORMATS section below.
.TP
\fB\-i\fR <path>, \fB\-\-input\fR <path>
Read the topology from <path> instead of discovering the topology of the local machine.
If <path> is a file and XML support has been compiled in hwloc,
it may be a XML file exported by a previous hwloc program.
If <path> is "\-", the standard input may be used as a 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.
.TP
\fB\-i\fR <specification>, \fB\-\-input\fR <specification>
Simulate 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.
.TP
\fB\-\-if\fR <format>, \fB\-\-input\-format\fR <format>
Enforce the input in the given format, among \fBxml\fR, \fBfsroot\fR,
\fBcpuid\fR and \fBsynthetic\fR.
.TP
\fB\-\-export\-xml\-flags\fR <flags>
Enforce flags when exporting to the XML format.
Flags may be given as numeric values or as a comma-separated list of flag names
that are passed to \fIhwloc_topology_export_xml()\fR.
Those names may be substrings of actual flag names as long as a single one matches.
A value of \fB1\fR (or \fBv1\fR) reverts to the format of hwloc v1.x.
The default is \fB0\fR (or \fBnone\fR).
.TP
\fB\-\-export\-synthetic\-flags\fR <flags>
Enforce flags when exporting to the synthetic format.
Flags may be given as numeric values or as a comma-separated list of flag names
that are passed to \fIhwloc_topology_export_synthetic()\fR.
Those names may be substrings of actual flag names as long as a single one matches.
A value of \fB2\fR (or \fBno_attr\fR) reverts to the format of hwloc v1.9.
A value of \fB3\fR (or \fBno_ext,no_attr\fR) reverts to the original minimalistic format (before v1.9).
The default is \fB0\fR (or \fBnone\fR).
.TP
\fB\-v\fR \fB\-\-verbose\fR
Include additional detail.
The hwloc-info tool may be used to display even more information
about specific objects.
.TP
\fB\-s\fR \fB\-\-silent\fR
Reduce the amount of details to show.
.TP
\fB\-\-distances\fR
Only display distance matrices.
.TP
\fB\-\-distances-transform\fR <links|merge-switch-ports|transitive-closure>
Try applying a transformation to distances structures before displaying them.
See hwloc_distances_transform() for details.
More transformations may be applied using hwloc-annotate(1)
(and it may save their output to XML).
.TP
\fB\-\-memattrs\fR
Only display memory attributes.
All of them are displayed (while the default textual output selects
memory attribute details depending on the verbosity level).
.TP
\fB\-\-cpukinds\fR
Only display CPU kinds.
CPU kinds are displayed in order, starting from the most energy efficient
ones up to the rather higher performance and power hungry ones.
.TP
\fB\-\-windows\-processor\-groups\fR
On Windows, only show information about processor groups.
All of them are displayed, while the default verbose output
only shows them if there are more than one.
.TP
\fB\-f\fR \fB\-\-force\fR
If the destination file already exists, overwrite it.
.TP
\fB\-l\fR \fB\-\-logical\fR
Display hwloc logical indexes of all objects, with prefix "L#".
.
By default, both logical and physical/OS indexes are displayed for PUs and NUMA nodes,
logical only for cores, dies and packages, and no index for other types.
.TP
\fB\-p\fR \fB\-\-physical\fR
Display OS/physical indexes of all objects, with prefix "P#".
.
By default, both logical and physical/OS indexes are displayed for PUs and NUMA nodes,
logical only for cores, dies and packages, and no index for other types.
.TP
\fB\-\-logical\-index\-prefix\fR <prefix>
Replace " L#" with the given prefix for logical indexes.
.TP
\fB\-\-os\-index\-prefix\fR <prefix>
Replace " P#" with the given prefix for physical/OS indexes.
.TP
\fB\-c\fR \fB\-\-cpuset\fR
Display the cpuset of each object.
.TP
\fB\-C\fR \fB\-\-cpuset\-only\fR
Only display the cpuset of each object; do not display anything else
about the object.
.TP
\fB\-\-taskset\fR
Show CPU set strings in the format recognized by the taskset command-line
program instead of hwloc-specific CPU set string format.
This option should be combined with \fB\-\-cpuset\fR or \fB\-\-cpuset\-only\fR,
otherwise it will imply \fB\-\-cpuset\fR.
.TP
\fB\-\-only\fR <type>
Only show objects of the given type in the textual output.
.TP
\fB\-\-filter\fR <type>:<kind>, \fB\-\-filter\fR <type>
Filter 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), only important objects are kept.
See hwloc_topology_set_type_filter() for more details.
hwloc supports filtering any type except PUs and NUMA nodes.
lstopo also offers PU and NUMA node filtering by hiding them in the graphical and textual outputs,
but any object included in them (for instance Misc) will be hidden as well.
Note that PUs and NUMA nodes may not be ignored in the XML output.
Note also that the top-level object type cannot be ignored (usually Machine or System).
.TP
\fB\-\-ignore\fR <type>
This is the old way to specify \fB-\-filter <type>:none\fR.
.TP
\fB\-\-no\-smt\fR
Ignore PUs.
This is identical to \fB-\-filter PU:none\fR.
.TP
\fB\-\-no\-caches\fR
Do not show caches.
This is identical to \fB-\-filter cache:none\fR.
.TP
\fB\-\-no\-useless\-caches\fR
This is identical to \fB-\-filter cache:structure\fR.
.TP
\fB\-\-no\-icaches\fR
This is identical to \fB-\-filter icache:none\fR.
.TP
\fB\-\-disallowed\fR
Include objects disallowed by administrative limitations (e.g Cgroups on Linux).
Offline PUs and NUMA nodes are still ignored.
.TP
\fB\-\-allow\fR <all|local|0xff|nodeset=0xf0>
Include objects disallowed by administrative limitations (implies \fB\-\-disallowed\fR)
and also change the set of allowed ones.
If \fBlocal\fR is given, only objects available to the current process are allowed
(default behavior when loading from the native operating system backend).
It may be useful if the topology was created by another process (with different
administrative restrictions such as Linux Cgroups) and loaded here loaded from XML
or synthetic.
This case implies \fB\-\-thissystem\fR.
If \fBall\fR, all objects are allowed.
If a bitmap is given as a hexadecimal string, it is used as the set of allowed PUs.
If a bitmap is given after prefix \fBnodeset=\fR, it is the set of allowed NUMA nodes.
.TP
\fB\-\-flags\fR <flags>
Enforce topology flags.
Flags may be given as numeric values or as a comma-separated list of flag names
that are passed to \fIhwloc_topology_set_flags()\fR.
Those names may be substrings of actual flag names as long as a single one matches,
for instance \fBdisallowed,thissystem_allowed\fR.
The default is \fB8\fR (or \fBimport\fR).
.TP
\fB\-\-merge\fR
Do not show levels that do not have a hierarchical impact.
This sets HWLOC_TYPE_FILTER_KEEP_STRUCTURE for all object types.
This is identical to \fB\-\-filter all:structure\fR.
.TP
\fB\-\-no\-factorize\fR \fB\-\-no\-factorize\fR=<type>
Never factorize identical objects in the graphical output.
If an object type is given, only factorizing of these objects is disabled.
This only applies to normal CPU-side objects, it is independent from PCI collapsing.
.TP
\fB\-\-factorize\fR \fB\-\-factorize\fR=[<type>,]<N>[,<L>[,<F>]
Factorize identical children in the graphical output (enabled by default).
If <N> is specified (4 by default), factorizing only occurs when there are strictly
more than N identical children.
If <L> and <F> are specified, they set the numbers of first and last children to keep
after factorizing.
If an object type is given, only factorizing of these objects is configured.
This only applies to normal CPU-side object, it is independent from PCI collapsing.
.TP
\fB\-\-no\-collapse\fR
Do not collapse identical PCI devices.
By default, identical sibling PCI devices (such as many virtual functions
inside a single physical device) are collapsed.
.TP
\fB\-\-no\-cpukinds\fR
Do not show different kinds of CPUs in the graphical output.
By default, when supported, different types of lines, thickness
and bold font may be used to display PU boxes of different kinds.
.TP
\fB\-\-restrict\fR <cpuset>
Restrict the topology to the given cpuset.
.TP
\fB\-\-restrict\fR nodeset=<nodeset>
Restrict the topology to the given nodeset, unless --restrict-flags specifies something different.
.TP
\fB\-\-restrict\fR binding
Restrict the topology to the current process binding.
This option requires the use of the actual current machine topology
(or any other topology with \fB\-\-thissystem\fR or with
HWLOC_THISSYSTEM set to 1 in the environment).
.TP
\fB\-\-restrict\-flags\fR <flags>
Enforce 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 \fIhwloc_topology_restrict()\fR.
Those names may be substrings of actual flag names as long as a single one matches,
for instance \fBbynodeset,memless\fR.
The default is \fB0\fR (or \fBnone\fR).
.TP
\fB\-\-no\-io\fB
Do not show any I/O device or bridge.
This is identical to \fB\-\-filter io:none\fR.
By default, common devices (GPUs, NICs, block devices, ...) and
interesting bridges/switches are shown.
.TP
\fB\-\-no\-bridges\fB
Do not show any I/O bridge except hostbridges.
This is identical to \fB\-\-filter bridge:none\fR.
By default, common devices (GPUs, NICs, block devices, ...) and
interesting bridges/switches are shown.
.TP
\fB\-\-whole\-io\fB
Show all I/O devices and bridges.
This is identical to \fB\-\-filter io:all\fR.
By default, only common devices (GPUs, NICs, block devices, ...) and
interesting bridges/switches are shown.
.TP
\fB\-\-thissystem\fR
Assume that the selected backend provides the topology for the
system on which we are running.
This is useful when loading a custom topology such as an XML file
and using \fB\-\-restrict binding\fR or \fB\-\-allow all\fR.
.TP
\fB\-\-pid\fR <pid>
Detect topology as seen by process <pid>, i.e. as if process <pid> did the
discovery itself.
Note that this can for instance change the set of allowed processors.
Also show this process current CPU and Memory binding by marking the corresponding
PUs and NUMA nodes (in Green in the graphical output, see the COLORS section below,
or by appending \fI(binding)\fR to the verbose text output).
If 0 is given as pid, the current binding for the lstopo process will be shown.
.TP
\fB\-\-ps\fR \fB\-\-top\fR
Show existing processes as misc objects in the output. To avoid uselessly
cluttering the output, only processes that are restricted to some part of the
machine are shown. On Linux, kernel threads are not shown.
If many processes appear, the output may become hard to read anyway,
making the hwloc-ps program more practical.
.TP
\fB\-\-children\-order\fR <order>
Change the order of the different kinds of children with respect to
their parent in the graphical output.
\fI<order>\fR may be a comma-separated list of keywords among:
\fImemory:above\fR displays memory children above other children
(and above the parent if it is a cache).
PUs are therefore below their local NUMA nodes, like hwloc 1.x did.
\fIio:right\fR and \fImisc:right\fR place I/O or Misc children
on the right of CPU children.
\fIio:below\fR and \fImisc:below\fR place I/O or Misc children
below CPU children.
\fIplain\fR places everything not specified together with
normal CPU children.
If only \fIplain\fR is specified, lstopo displays the topology
in a basic manner that strictly matches the actual tree:
Memory, I/O and Misc children are listed below their parent just like any other child.
PUs are therefore on the side of their local NUMA nodes,
below a common ancestor.
This output may result in strange layouts since the size of Memory,
CPU and I/O children may be very different, causing the placement
algorithm to poorly arrange them in rows.
The default order is \fImemory:above,io:right,misc:right\fR which means
Memory children are above CPU children while I/O and Misc are together
on the right.
Up to hwloc 2.5, the default was rather to \fImemory:above,plain\fR.
Additionally, \fIio:right\fR, \fIio:below\fR, \fImisc:right\fR
and \fImisc:below\fR may be suffixed with
\fI:horiz\fR, \fI:vert\fR or \fI:rect\fR to force the horizontal,
vertical or rectangular layout of children inside these sections.
See also the GRAPHICAL OUTPUT and LAYOUT sections below.
.TP
\fB\-\-fontsize\fR <size>
Set the size of text font in the graphical output.
The default is 10.
Boxes are scaled according to the text size.
The \fILSTOPO_TEXT_XSCALE\fR environment variable may be used
to further scale the width of boxes (its default value is 1.0).
The \fB\-\-fontsize\fR option is ignored in the ASCII backend.
.TP
\fB\-\-gridsize\fR <size>
Set the margin between elements in the graphical output.
The default is 7. It was 10 prior to hwloc 2.1.
This option is ignored in the ASCII backend.
.TP
\fB\-\-linespacing\fR <size>
Set the spacing between lines of text in the graphical output.
The default is 4.
The option was included in \fB\-\-gridsize\fR prior to hwloc 2.1 (and its default was 10).
This option is ignored in the ASCII backend.
.TP
\fB\-\-thickness\fR <size>
Set the thickness of lines and boxes in the graphical output.
The default is 1.
This option is ignored in the ASCII backend.
.TP
\fB\-\-horiz\fR, \fB\-\-horiz\fR=<type1,...>
Force a horizontal graphical layout instead of nearly 4/3 ratio in the graphical output.
If a comma-separated list of object types is given, the layout only
applies to the corresponding \fIcontainer\fR objects.
Ignored for bridges since their children are always vertically aligned.
.TP
\fB\-\-vert\fR, \fB\-\-vert\fR=<type1,...>
Force a vertical graphical layout instead of nearly 4/3 ratio in the graphical output.
If a comma-separated list of object types is given, the layout only
applies to the corresponding \fIcontainer\fR objects.
.TP
\fB\-\-rect\fR, \fB\-\-rect\fR=<type1,...>
Force a rectangular graphical layout with nearly 4/3 ratio in the graphical output.
If a comma-separated list of object types is given, the layout only
applies to the corresponding \fIcontainer\fR objects.
Ignored for bridges since their children are always vertically aligned.
.TP
\fB\-\-no\-text\fR, \fB\-\-no\-text\fR=<type1,...>
Do not display any text in boxes in the graphical output.
If a comma-separated list of object types is given, text is disabled for the corresponding objects.
This is mostly useful for removing text from Group objects.
.TP
\fB\-\-text\fR, \fB\-\-text\fR=<type1,...>
Display text in boxes in the graphical output (default).
If a comma-separated list of object types is given, text is reenabled for the corresponding objects
(if it was previously disabled with \fB\-\-no\-text\fR).
.TP
\fB\-\-no\-index\fR, \fB\-\-no\-index\fR=<type1,...>
Do not show object indexes in the graphical output.
If a comma-separated list of object types is given, indexes are disabled for the corresponding objects.
.TP
\fB\-\-index\fR, \fB\-\-index=\fR<type1,...>
Show object indexes in the graphical output (default).
If a comma-separated list of object types is given, indexes are reenabled for the corresponding objects
(if they were previously disabled with \fB\-\-no\-index\fR).
.TP
\fB\-\-no\-attrs\fR, \fB\-\-no\-attrs\fR=<type1,...>
Do not show object attributes (such as memory size, cache size, PCI bus ID, PCI link speed, etc.)
in the graphical output.
If a comma-separated list of object types is given, attributes are disabled for the corresponding objects.
.TP
\fB\-\-attrs\fR, \fB\-\-attrs=\fR<type1,...>
Show object attributes (such as memory size, cache size, PCI bus ID, PCI link speed, etc.)
in the graphical output (default).
If a comma-separated list of object types is given, attributes are reenabled for the corresponding objects
(if they were previously disabled with \fB\-\-no\-attrs\fR).
.TP
\fB\-\-no\-legend\fR
Remove all text legend lines at the bottom of the graphical output.
.TP
\fB\-\-no\-default\-legend\fR
Remove default text legend lines at the bottom of the graphical output.
User-added legend lines with \fB\-\-append\-legend\fB or the "lstopoLegend" info
are still displayed if any.
.TP
\fB\-\-append\-legend\fR <line>
Append the line of text to the bottom of the legend in the graphical output.
If adding multiple lines, each line should be given separately by
passing this option multiple times.
Additional legend lines may also be specified inside the topology using the
"lstopoLegend" info attributes on the topology root object.
.TP
\fB\-\-grey\fR, \fB\-\-greyscale\fR
Use greyscale instead of colors in the graphical output.
.TP
\fB\-\-palette\fR <grey|greyscale|defaut|colors|white|none>
Change the color palette.
Passing \fIgrey\fR or \fIgreyscale\fR is identical to passing \fB\-\-grey\fR or \fB\-\-greyscale\fR.
Passing \fIwhite\fR or \fInone\fR uses white instead of colors for all box backgrounds.
Passing \fIdefault\fR or \fIcolors\fR reverts back to the default color palette.
.TP
\fB\-\-palette\fR type=#rrggbb
Replace the color of the given box type with the given 3x8bit hexadecimal RGB combination (e.g. \fI#ff0000\fR is red).
Existing types are \fImachine\fR, \fIgroup\fR, \fIpackage\fR, \fIgroup_in_package\fR, \fIdie\fR, \fIcore\fR, \fIpu\fR, \fInumanode\fR, \fImemories\fR (box containing multiple memory children), \fIcache\fR, \fIpcidev\fR, \fIosdev\fR, \fIbridge\fR, and \fImisc\fR.
See also CUSTOM COLOR below for customizing individual objects.
.TP
\fB\-\-binding\-color\fR <none|#rrggbb>
Do not colorize PUs and NUMA nodes according to the binding in the graphical output.
Or change the color to the given 3x8bit hexadecimal RGB combination (e.g. \fI#ff0000\fR is red).
.TP
\fB\-\-disallowed\-color\fR <none|#rrggbb>
Do not colorize disallowed PUs and NUMA nodes in the graphical output.
Or change the color to the given 3x8bit hexadecimal RGB combination (e.g. \fI#00ff00\fR is green).
.TP
\fB\-\-top\-color\fR <none|#rrggbb>
Do not colorize task objects in the graphical output when \-\-top is given.
Or change the color to the given 3x8bit hexadecimal RGB combination (e.g. \fI#0000ff\fR is blue).
.TP
\fB\-\-version\fR
Report version and exit.
.TP
\fB\-h\fR \fB\-\-help\fR
Display help message and exit.
.
.\" --shmem-output-addr is undocumented on purpose
.
.\" **************************
.\" Description Section
.\" **************************
.SH DESCRIPTION
.
lstopo and lstopo-no-graphics are capable of displaying a topological map of
the system in a variety of different output formats. The only difference
between lstopo and lstopo-no-graphics is that graphical outputs are only
supported by lstopo, to reduce dependencies on external libraries.
hwloc-ls is identical to lstopo-no-graphics.
.
.PP
The filename specified directly implies the output format that will be
used; see the OUTPUT FORMATS section, below. Output formats that
support color will indicate specific characteristics about individual
CPUs by their color; see the COLORS section, below.
.
.\" **************************
.\" Output Formats Section
.\" **************************
.SH OUTPUT FORMATS
.
.PP
By default, if no output filename is specific, the output is sent
to a graphical window if possible in the current environment
(DISPLAY environment variable set on Unix, etc.).
Otherwise, a text summary is displayed in the console.
The console is also used when the program runs from a terminal
and the output is redirected to a pipe or file.
These default behaviors may be changed by passing \fB\-\-of console\fR
to force console mode or \fB\-\-of window\fR for graphical window.
.
.PP
The filename on the command line usually determines the format of the output.
There are a few filenames that indicate specific output formats and
devices (e.g., a filename of "-" will output a text summary to
stdout), but most filenames indicate the desired output format by
their suffix (e.g., "topo.png" will output a PNG-format file).
.PP
The format of the output may also be changed with "\-\-of".
For instance, "\-\-of pdf" will generate a PDF-format file on the standard
output, while "\-\-of fig toto" will output a Xfig-format file named "toto".
.
.PP
The list of currently supported formats is given below. Any of them may
be used with "\-\-of" or as a filename suffix.
.TP
.B default
Send the output to a window or to the console depending on the environment.
.
.TP
.B window
Send the output to a graphical window.
.
.TP
.B console
Send a text summary to stdout.
Binding or unallowed processors are only annotated in this mode
if verbose; see the COLORS section, below.
.
.TP
.B ascii
Output an ASCII art representation of the map
(formerly called \fBtxt\fR).
If outputting to stdout and if colors are supported on the terminal,
the output will be colorized.
.
.TP
\fBtikz\fR or \fBtex\fR
Output a LaTeX tikzpicture representation of the map that can be
compiled with a LaTeX compiler.
.
.TP
.B fig
Output a representation of the map that can be loaded in Xfig.
.
.TP
.B svg
Output a SVG representation of the map,
using Cairo (by default, if supported)
or a native SVG backend (fallback, always supported).
See \fBcairosvg\fR and \fBnativesvg\fR below.
.
.TP
\fBcairosvg\fR or \fBsvg(cairo)\fR
If lstopo was compiled with the proper support,
output a SVG representation of the map using Cairo.
.
.TP
\fBnativesvg\fR or \fBsvg(native)\fR
Output a SVG representation of the map using the native SVG backend.
It may be less pretty than the Cairo output, but it is always supported,
and SVG objects have attributes for identifying and manipulating them.
See dynamic_SVG_example.html for an example.
.
.TP
.B pdf
If lstopo was compiled with the proper
support, lstopo outputs a PDF representation of the map.
.
.TP
.B ps
If lstopo was compiled with the proper
support, lstopo outputs a Postscript representation of the map.
.
.TP
.B png
If lstopo was compiled with the proper
support, lstopo outputs a PNG representation of the map.
.
.TP
.B synthetic
If the topology is symmetric
(which requires that the root object has its symmetric_subtree field set),
lstopo outputs a synthetic description string.
This output may be reused as an input synthetic topology
description later.
See also the Synthetic topologies section in the documentation.
Note that Misc and I/O devices are ignored during this export.
.
.TP
.B xml
If lstopo was compiled with the proper
support, lstopo outputs an XML representation of the map.
It may be reused later, even on another machine, with lstopo \-\-input,
the HWLOC_XMLFILE environment variable, or the hwloc_topology_set_xml()
function.
.PP
The following special names may be used:
.TP
.B \-
Send a text summary to stdout.
.
.TP
.B /dev/stdout
Send a text summary to stdout. It is effectively the same as
specifying "\-".
.
.TP
.B \-.<format>
If the entire filename is "\-.<format>", lstopo behaves as if
"\-\-of <format> -" was given, which means a file of the given format
is sent to the standard output.
.PP
See the output of "lstopo \-\-help" for a specific list of what
graphical output formats are supported in your hwloc installation.
.
.\" **************************
.\" Graphical Section
.\" **************************
.
.SH GRAPHICAL OUTPUT
The graphical output is made of nested boxes representing
the inclusion of objects in the hierarchy of resources.
Usually a Machine box contains one or several Package boxes,
that contain multiple Core boxes, with one or several PUs each.
.SS Caches
Caches are displayed in a slightly different manner because
they do not actually include computing resources such as cores.
For instance, a L2 Cache shared by a pair of Cores is drawn
as a Cache box on top of two Core boxes
(instead of having Core boxes inside the Cache box).
.SS NUMA nodes and Memory-side Caches
By default, NUMA nodes boxes are drawn on top of their local
computing resources.
For instance, a processor Package containing one NUMA node
and four Cores is displayed as a Package box containing
the NUMA node box above four Core boxes.
If a NUMA node is local to the L3 Cache, the NUMA node is displayed
above that Cache box.
All this specific drawing strategy for memory objects may be disabled
by passing command-line option \fB\-\-children\-order plain\fR.
If multiple NUMA nodes are attached to the same parent object,
they are displayed inside an additional unnamed memory box.
If some Memory-side Caches exist in front of some NUMA nodes,
they are drawn as boxes immediately above them.
.SS PCI bridges, PCI devices and OS devices
The PCI hierarchy is not drawn as a set of included boxes but rather
as a tree of bridges (that may actually be switches) with links between them.
The tree starts with a small square on the left for the
hostbridge or root complex.
It ends with PCI device boxes on the right.
Intermediate PCI bridges/switches may appear as additional small
squares in the middle.
PCI devices on the right of the tree are boxes containing
their PCI bus ID (such as 00:02.3).
They may also contain sub-boxes for OS device objects
such as a network interface \fIeth0\fR or a CUDA GPU \fIcuda0\fR.
When there is a single link (horizontal line) on the right of a
PCI bridge, it means that a single device or bridge is connected
on the secondary PCI bus behind that bridge.
When there is a vertical line, it means that multiple devices
and/or bridges are connected to the same secondary PCI bus.
The datarate of a PCI link may be written (in GB/s) right below
its drawn line (if the operating system and/or libraries are able
to report that information).
This datarate is the currently configured speed of the entire PCI link
(sum of the bandwidth of all PCI lanes in that link).
It may change during execution since some devices are able to
slow their PCI links down when idle.
.
.\" **************************
.\" Layout Section
.\" **************************
.SH LAYOUT
In its graphical output, lstopo uses simple rectangular heuristics
to try to achieve a 4/3 ratio between width and height.
Although the hierarchy of resources is properly reflected,
the exact physical organization (NUMA distances, rings,
complete graphs, etc.) is currently ignored.
The layout of a level may be changed with \fB\-\-vert\fR, \fB\-\-horiz\fR,
and \fB\-\-rect\fR to force a parent object to arrange its children
in vertical, horizontal or rectangular manners respectively.
The position of Memory, I/O and Misc children with respect to other
children objects may be changed using \fB\-\-children\-order\fR.
This effectivement divides children into multiple sections.
The layout of children is first computed inside each section,
before sections are placed inside (or below) the parent box.
The vertical/horizontal/rectangular layout of these additional
sections may also be configured through \fB\-\-children\-order\fR.
.
.\" **************************
.\" Colors Section
.\" **************************
.SH COLORS
Individual CPUs and NUMA nodes are colored in the graphical output
formats to indicate different characteristics:
.TP
Green
The topology is reported as seen by a specific process (see \fB\-\-pid\fR),
and the given CPU or NUMA node is in this process CPU or Memory binding mask.
.TP
White
The CPU or NUMA node is in the allowed set (see below).
If the topology is reported as seen by a specific process (see \fB\-\-pid\fR),
the object is also not in this process binding mask.
.TP
Red
The CPU or NUMA node is not in the allowed set (see below).
.
.PP
The "allowed set" is the set of CPUs or NUMA nodes to which the current process is
allowed to bind. The allowed set is usually either inherited from the
parent process or set by administrative qpolicies on the system. Linux
cpusets are one example of limiting the allowed set for a process and
its children to be less than the full set of CPUs or NUMA nodes on the system.
.PP
Different processes may therefore have different CPUs or NUMA nodes in the allowed
set. Hence, invoking lstopo in different contexts and/or as different
users may display different colors for the same individual CPUs (e.g.,
running lstopo in one context may show a specific CPU as red, but
running lstopo in a different context may show the same CPU as white).
.PP
Some lstopo output modes, e.g. the console mode (default non-graphical output),
do not support colors at all.
The console mode displays the above characteristics by appending text
to each PU line if verbose messages are enabled.
.
.SH CUSTOM COLORS
The colors of different kinds of boxes may be configured with \fB\-\-palette\fR.
The color of each object in the graphical output may also be enforced by
specifying a "lstopoStyle" info attribute in that object.
Its value should be a semi-colon separated list of "<attribute>=#rrggbb"
where rr, gg and bb are the RGB components of a color,
each between 0 and 255, in hexadecimal (00 to ff).
.
<attribute> may be
.TP
\fBBackground\fR
Sets the background color of the main object box.
.TP
\fBText\fR
Sets the color of the text showing the object name, type, index, etc.
.TP
\fBText2\fB
Sets the color of the additional text near the object,
for instance the link speed behind a PCI bridge.
.PP
The "lstopoStyle" info may be added to a temporarily-saved XML topologies
with hwloc-annotate, or with hwloc_obj_add_info().
.
For instance, to display all core objects in blue (with white names):
lstopo save.xml
hwloc-annotate save.xml save.xml core:all info lstopoStyle "Background=#0000ff;Text=#ffffff"
lstopo -i save.xml
.
.\" **************************
.\" Examples Section
.\" **************************
.SH EXAMPLES
.
To display the machine topology in textual mode:
lstopo-no-graphics
To display the machine topology in ascii-art mode:
lstopo-no-graphics -.ascii
To display in graphical mode (assuming that the DISPLAY environment
variable is set to a relevant value):
lstopo
To export the topology to a PNG file:
lstopo file.png
To export an XML file on a machine and later display the corresponding
graphical output on another machine:
machine1$ lstopo file.xml
<transfer file.xml from machine1 to machine2>
machine2$ lstopo --input file.xml
To save the current machine topology to XML and later reload it faster
while still considering it as the current machine:
$ lstopo file.xml
<...>
$ lstopo --input file.xml --thissystem
To restrict an XML topology to only physical processors 0, 1, 4 and 5:
lstopo --input file.xml --restrict 0x33 newfile.xml
To restrict an XML topology to only numa node whose logical index is 1:
lstopo --input file.xml --restrict $(hwloc-calc --input file.xml node:1) newfile.xml
To display a summary of the topology:
lstopo -s
To get more details about the topology:
lstopo -v
To only show cores:
lstopo --only core
To show cpusets:
lstopo --cpuset
To only show the cpusets of package:
lstopo --only package --cpuset-only
Simulate a fake hierarchy; this example shows with 2 NUMA nodes of 2
processor units:
lstopo --input "node:2 2"
To count the number of logical processors in the system
lstopo --only pu | wc -l
To append the kernel release and version to the graphical legend:
lstopo --append-legend "Kernel release: $(uname -r)" --append-legend "Kernel version: $(uname -v)"
.
.\" **************************
.\" Notes Section
.\" **************************
.SH NOTES
.
lstopo displays memory and cache sizes with units such as
\fBkB\fR (1 kilobyte = 1000 bytes) or \fBGB\fR (1 gigabyte = 1000*1000*1000 bytes)
while it actually means
\fBKiB\fR (1 kibibyte = 1024 bytes) or \fBGiB\fR (1 gibibytes = 1024*1024*1024 bytes) .
.
.\" **************************
.\" See also section
.\" **************************
.SH SEE ALSO
.
.ft R
hwloc(7), hwloc-info(1), hwloc-bind(1), hwloc-annotate(1), hwloc-ps(1), hwloc-gather-topology(1), hwloc-gather-cpuid(1)
.sp
-874
View File
@@ -1,874 +0,0 @@
.\" -*- nroff -*-
.\" Copyright © 2009-2022 Inria. All rights reserved.
.\" Copyright © 2009-2010 Université of Bordeaux
.\" Copyright © 2009-2010 Cisco Systems, Inc. All rights reserved.
.\" Copyright © 2020 Hewlett Packard Enterprise. All rights reserved.
.\" See COPYING in top-level directory.
.TH LSTOPO "1" "Dec 14, 2022" "2.9.0" "hwloc"
.SH NAME
lstopo, lstopo-no-graphics, hwloc-ls \- Show the topology of the system
.
.\" **************************
.\" Synopsis Section
.\" **************************
.SH SYNOPSIS
.
.B lstopo
[ \fIoptions \fR]... [ \fIfilename \fR]
.
.PP
.B lstopo-no-graphics
[ \fIoptions \fR]... [ \fIfilename \fR]
.
.PP
.B hwloc-ls
[ \fIoptions \fR]... [ \fIfilename \fR]
.
.PP
Note that hwloc(7) provides a detailed explanation of the hwloc system; it
should be read before reading this man page
.
.\" **************************
.\" Options Section
.\" **************************
.SH OPTIONS
.
.TP
\fB\-\-of\fR <format>, \fB\-\-output\-format\fR <format>
Enforce the output in the given format.
See the OUTPUT FORMATS section below.
.TP
\fB\-i\fR <path>, \fB\-\-input\fR <path>
Read the topology from <path> instead of discovering the topology of the local machine.
If <path> is a file and XML support has been compiled in hwloc,
it may be a XML file exported by a previous hwloc program.
If <path> is "\-", the standard input may be used as a 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.
.TP
\fB\-i\fR <specification>, \fB\-\-input\fR <specification>
Simulate 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.
.TP
\fB\-\-if\fR <format>, \fB\-\-input\-format\fR <format>
Enforce the input in the given format, among \fBxml\fR, \fBfsroot\fR,
\fBcpuid\fR and \fBsynthetic\fR.
.TP
\fB\-\-export\-xml\-flags\fR <flags>
Enforce flags when exporting to the XML format.
Flags may be given as numeric values or as a comma-separated list of flag names
that are passed to \fIhwloc_topology_export_xml()\fR.
Those names may be substrings of actual flag names as long as a single one matches.
A value of \fB1\fR (or \fBv1\fR) reverts to the format of hwloc v1.x.
The default is \fB0\fR (or \fBnone\fR).
.TP
\fB\-\-export\-synthetic\-flags\fR <flags>
Enforce flags when exporting to the synthetic format.
Flags may be given as numeric values or as a comma-separated list of flag names
that are passed to \fIhwloc_topology_export_synthetic()\fR.
Those names may be substrings of actual flag names as long as a single one matches.
A value of \fB2\fR (or \fBno_attr\fR) reverts to the format of hwloc v1.9.
A value of \fB3\fR (or \fBno_ext,no_attr\fR) reverts to the original minimalistic format (before v1.9).
The default is \fB0\fR (or \fBnone\fR).
.TP
\fB\-v\fR \fB\-\-verbose\fR
Include additional detail.
The hwloc-info tool may be used to display even more information
about specific objects.
.TP
\fB\-s\fR \fB\-\-silent\fR
Reduce the amount of details to show.
.TP
\fB\-\-distances\fR
Only display distance matrices.
.TP
\fB\-\-distances-transform\fR <links|merge-switch-ports|transitive-closure>
Try applying a transformation to distances structures before displaying them.
See hwloc_distances_transform() for details.
More transformations may be applied using hwloc-annotate(1)
(and it may save their output to XML).
.TP
\fB\-\-memattrs\fR
Only display memory attributes.
All of them are displayed (while the default textual output selects
memory attribute details depending on the verbosity level).
.TP
\fB\-\-cpukinds\fR
Only display CPU kinds.
CPU kinds are displayed in order, starting from the most energy efficient
ones up to the rather higher performance and power hungry ones.
.TP
\fB\-\-windows\-processor\-groups\fR
On Windows, only show information about processor groups.
All of them are displayed, while the default verbose output
only shows them if there are more than one.
.TP
\fB\-f\fR \fB\-\-force\fR
If the destination file already exists, overwrite it.
.TP
\fB\-l\fR \fB\-\-logical\fR
Display hwloc logical indexes of all objects, with prefix "L#".
.
By default, both logical and physical/OS indexes are displayed for PUs and NUMA nodes,
logical only for cores, dies and packages, and no index for other types.
.TP
\fB\-p\fR \fB\-\-physical\fR
Display OS/physical indexes of all objects, with prefix "P#".
.
By default, both logical and physical/OS indexes are displayed for PUs and NUMA nodes,
logical only for cores, dies and packages, and no index for other types.
.TP
\fB\-\-logical\-index\-prefix\fR <prefix>
Replace " L#" with the given prefix for logical indexes.
.TP
\fB\-\-os\-index\-prefix\fR <prefix>
Replace " P#" with the given prefix for physical/OS indexes.
.TP
\fB\-c\fR \fB\-\-cpuset\fR
Display the cpuset of each object.
.TP
\fB\-C\fR \fB\-\-cpuset\-only\fR
Only display the cpuset of each object; do not display anything else
about the object.
.TP
\fB\-\-taskset\fR
Show CPU set strings in the format recognized by the taskset command-line
program instead of hwloc-specific CPU set string format.
This option should be combined with \fB\-\-cpuset\fR or \fB\-\-cpuset\-only\fR,
otherwise it will imply \fB\-\-cpuset\fR.
.TP
\fB\-\-only\fR <type>
Only show objects of the given type in the textual output.
.TP
\fB\-\-filter\fR <type>:<kind>, \fB\-\-filter\fR <type>
Filter 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), only important objects are kept.
See hwloc_topology_set_type_filter() for more details.
hwloc supports filtering any type except PUs and NUMA nodes.
lstopo also offers PU and NUMA node filtering by hiding them in the graphical and textual outputs,
but any object included in them (for instance Misc) will be hidden as well.
Note that PUs and NUMA nodes may not be ignored in the XML output.
Note also that the top-level object type cannot be ignored (usually Machine or System).
.TP
\fB\-\-ignore\fR <type>
This is the old way to specify \fB-\-filter <type>:none\fR.
.TP
\fB\-\-no\-smt\fR
Ignore PUs.
This is identical to \fB-\-filter PU:none\fR.
.TP
\fB\-\-no\-caches\fR
Do not show caches.
This is identical to \fB-\-filter cache:none\fR.
.TP
\fB\-\-no\-useless\-caches\fR
This is identical to \fB-\-filter cache:structure\fR.
.TP
\fB\-\-no\-icaches\fR
This is identical to \fB-\-filter icache:none\fR.
.TP
\fB\-\-disallowed\fR
Include objects disallowed by administrative limitations (e.g Cgroups on Linux).
Offline PUs and NUMA nodes are still ignored.
.TP
\fB\-\-allow\fR <all|local|0xff|nodeset=0xf0>
Include objects disallowed by administrative limitations (implies \fB\-\-disallowed\fR)
and also change the set of allowed ones.
If \fBlocal\fR is given, only objects available to the current process are allowed
(default behavior when loading from the native operating system backend).
It may be useful if the topology was created by another process (with different
administrative restrictions such as Linux Cgroups) and loaded here loaded from XML
or synthetic.
This case implies \fB\-\-thissystem\fR.
If \fBall\fR, all objects are allowed.
If a bitmap is given as a hexadecimal string, it is used as the set of allowed PUs.
If a bitmap is given after prefix \fBnodeset=\fR, it is the set of allowed NUMA nodes.
.TP
\fB\-\-flags\fR <flags>
Enforce topology flags.
Flags may be given as numeric values or as a comma-separated list of flag names
that are passed to \fIhwloc_topology_set_flags()\fR.
Those names may be substrings of actual flag names as long as a single one matches,
for instance \fBdisallowed,thissystem_allowed\fR.
The default is \fB8\fR (or \fBimport\fR).
.TP
\fB\-\-merge\fR
Do not show levels that do not have a hierarchical impact.
This sets HWLOC_TYPE_FILTER_KEEP_STRUCTURE for all object types.
This is identical to \fB\-\-filter all:structure\fR.
.TP
\fB\-\-no\-factorize\fR \fB\-\-no\-factorize\fR=<type>
Never factorize identical objects in the graphical output.
If an object type is given, only factorizing of these objects is disabled.
This only applies to normal CPU-side objects, it is independent from PCI collapsing.
.TP
\fB\-\-factorize\fR \fB\-\-factorize\fR=[<type>,]<N>[,<L>[,<F>]
Factorize identical children in the graphical output (enabled by default).
If <N> is specified (4 by default), factorizing only occurs when there are strictly
more than N identical children.
If <L> and <F> are specified, they set the numbers of first and last children to keep
after factorizing.
If an object type is given, only factorizing of these objects is configured.
This only applies to normal CPU-side object, it is independent from PCI collapsing.
.TP
\fB\-\-no\-collapse\fR
Do not collapse identical PCI devices.
By default, identical sibling PCI devices (such as many virtual functions
inside a single physical device) are collapsed.
.TP
\fB\-\-no\-cpukinds\fR
Do not show different kinds of CPUs in the graphical output.
By default, when supported, different types of lines, thickness
and bold font may be used to display PU boxes of different kinds.
.TP
\fB\-\-restrict\fR <cpuset>
Restrict the topology to the given cpuset.
.TP
\fB\-\-restrict\fR nodeset=<nodeset>
Restrict the topology to the given nodeset, unless --restrict-flags specifies something different.
.TP
\fB\-\-restrict\fR binding
Restrict the topology to the current process binding.
This option requires the use of the actual current machine topology
(or any other topology with \fB\-\-thissystem\fR or with
HWLOC_THISSYSTEM set to 1 in the environment).
.TP
\fB\-\-restrict\-flags\fR <flags>
Enforce 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 \fIhwloc_topology_restrict()\fR.
Those names may be substrings of actual flag names as long as a single one matches,
for instance \fBbynodeset,memless\fR.
The default is \fB0\fR (or \fBnone\fR).
.TP
\fB\-\-no\-io\fB
Do not show any I/O device or bridge.
This is identical to \fB\-\-filter io:none\fR.
By default, common devices (GPUs, NICs, block devices, ...) and
interesting bridges/switches are shown.
.TP
\fB\-\-no\-bridges\fB
Do not show any I/O bridge except hostbridges.
This is identical to \fB\-\-filter bridge:none\fR.
By default, common devices (GPUs, NICs, block devices, ...) and
interesting bridges/switches are shown.
.TP
\fB\-\-whole\-io\fB
Show all I/O devices and bridges.
This is identical to \fB\-\-filter io:all\fR.
By default, only common devices (GPUs, NICs, block devices, ...) and
interesting bridges/switches are shown.
.TP
\fB\-\-thissystem\fR
Assume that the selected backend provides the topology for the
system on which we are running.
This is useful when loading a custom topology such as an XML file
and using \fB\-\-restrict binding\fR or \fB\-\-allow all\fR.
.TP
\fB\-\-pid\fR <pid>
Detect topology as seen by process <pid>, i.e. as if process <pid> did the
discovery itself.
Note that this can for instance change the set of allowed processors.
Also show this process current CPU and Memory binding by marking the corresponding
PUs and NUMA nodes (in Green in the graphical output, see the COLORS section below,
or by appending \fI(binding)\fR to the verbose text output).
If 0 is given as pid, the current binding for the lstopo process will be shown.
.TP
\fB\-\-ps\fR \fB\-\-top\fR
Show existing processes as misc objects in the output. To avoid uselessly
cluttering the output, only processes that are restricted to some part of the
machine are shown. On Linux, kernel threads are not shown.
If many processes appear, the output may become hard to read anyway,
making the hwloc-ps program more practical.
.TP
\fB\-\-children\-order\fR <order>
Change the order of the different kinds of children with respect to
their parent in the graphical output.
\fI<order>\fR may be a comma-separated list of keywords among:
\fImemory:above\fR displays memory children above other children
(and above the parent if it is a cache).
PUs are therefore below their local NUMA nodes, like hwloc 1.x did.
\fIio:right\fR and \fImisc:right\fR place I/O or Misc children
on the right of CPU children.
\fIio:below\fR and \fImisc:below\fR place I/O or Misc children
below CPU children.
\fIplain\fR places everything not specified together with
normal CPU children.
If only \fIplain\fR is specified, lstopo displays the topology
in a basic manner that strictly matches the actual tree:
Memory, I/O and Misc children are listed below their parent just like any other child.
PUs are therefore on the side of their local NUMA nodes,
below a common ancestor.
This output may result in strange layouts since the size of Memory,
CPU and I/O children may be very different, causing the placement
algorithm to poorly arrange them in rows.
The default order is \fImemory:above,io:right,misc:right\fR which means
Memory children are above CPU children while I/O and Misc are together
on the right.
Up to hwloc 2.5, the default was rather to \fImemory:above,plain\fR.
Additionally, \fIio:right\fR, \fIio:below\fR, \fImisc:right\fR
and \fImisc:below\fR may be suffixed with
\fI:horiz\fR, \fI:vert\fR or \fI:rect\fR to force the horizontal,
vertical or rectangular layout of children inside these sections.
See also the GRAPHICAL OUTPUT and LAYOUT sections below.
.TP
\fB\-\-fontsize\fR <size>
Set the size of text font in the graphical output.
The default is 10.
Boxes are scaled according to the text size.
The \fILSTOPO_TEXT_XSCALE\fR environment variable may be used
to further scale the width of boxes (its default value is 1.0).
The \fB\-\-fontsize\fR option is ignored in the ASCII backend.
.TP
\fB\-\-gridsize\fR <size>
Set the margin between elements in the graphical output.
The default is 7. It was 10 prior to hwloc 2.1.
This option is ignored in the ASCII backend.
.TP
\fB\-\-linespacing\fR <size>
Set the spacing between lines of text in the graphical output.
The default is 4.
The option was included in \fB\-\-gridsize\fR prior to hwloc 2.1 (and its default was 10).
This option is ignored in the ASCII backend.
.TP
\fB\-\-thickness\fR <size>
Set the thickness of lines and boxes in the graphical output.
The default is 1.
This option is ignored in the ASCII backend.
.TP
\fB\-\-horiz\fR, \fB\-\-horiz\fR=<type1,...>
Force a horizontal graphical layout instead of nearly 4/3 ratio in the graphical output.
If a comma-separated list of object types is given, the layout only
applies to the corresponding \fIcontainer\fR objects.
Ignored for bridges since their children are always vertically aligned.
.TP
\fB\-\-vert\fR, \fB\-\-vert\fR=<type1,...>
Force a vertical graphical layout instead of nearly 4/3 ratio in the graphical output.
If a comma-separated list of object types is given, the layout only
applies to the corresponding \fIcontainer\fR objects.
.TP
\fB\-\-rect\fR, \fB\-\-rect\fR=<type1,...>
Force a rectangular graphical layout with nearly 4/3 ratio in the graphical output.
If a comma-separated list of object types is given, the layout only
applies to the corresponding \fIcontainer\fR objects.
Ignored for bridges since their children are always vertically aligned.
.TP
\fB\-\-no\-text\fR, \fB\-\-no\-text\fR=<type1,...>
Do not display any text in boxes in the graphical output.
If a comma-separated list of object types is given, text is disabled for the corresponding objects.
This is mostly useful for removing text from Group objects.
.TP
\fB\-\-text\fR, \fB\-\-text\fR=<type1,...>
Display text in boxes in the graphical output (default).
If a comma-separated list of object types is given, text is reenabled for the corresponding objects
(if it was previously disabled with \fB\-\-no\-text\fR).
.TP
\fB\-\-no\-index\fR, \fB\-\-no\-index\fR=<type1,...>
Do not show object indexes in the graphical output.
If a comma-separated list of object types is given, indexes are disabled for the corresponding objects.
.TP
\fB\-\-index\fR, \fB\-\-index=\fR<type1,...>
Show object indexes in the graphical output (default).
If a comma-separated list of object types is given, indexes are reenabled for the corresponding objects
(if they were previously disabled with \fB\-\-no\-index\fR).
.TP
\fB\-\-no\-attrs\fR, \fB\-\-no\-attrs\fR=<type1,...>
Do not show object attributes (such as memory size, cache size, PCI bus ID, PCI link speed, etc.)
in the graphical output.
If a comma-separated list of object types is given, attributes are disabled for the corresponding objects.
.TP
\fB\-\-attrs\fR, \fB\-\-attrs=\fR<type1,...>
Show object attributes (such as memory size, cache size, PCI bus ID, PCI link speed, etc.)
in the graphical output (default).
If a comma-separated list of object types is given, attributes are reenabled for the corresponding objects
(if they were previously disabled with \fB\-\-no\-attrs\fR).
.TP
\fB\-\-no\-legend\fR
Remove all text legend lines at the bottom of the graphical output.
.TP
\fB\-\-no\-default\-legend\fR
Remove default text legend lines at the bottom of the graphical output.
User-added legend lines with \fB\-\-append\-legend\fB or the "lstopoLegend" info
are still displayed if any.
.TP
\fB\-\-append\-legend\fR <line>
Append the line of text to the bottom of the legend in the graphical output.
If adding multiple lines, each line should be given separately by
passing this option multiple times.
Additional legend lines may also be specified inside the topology using the
"lstopoLegend" info attributes on the topology root object.
.TP
\fB\-\-grey\fR, \fB\-\-greyscale\fR
Use greyscale instead of colors in the graphical output.
.TP
\fB\-\-palette\fR <grey|greyscale|defaut|colors|white|none>
Change the color palette.
Passing \fIgrey\fR or \fIgreyscale\fR is identical to passing \fB\-\-grey\fR or \fB\-\-greyscale\fR.
Passing \fIwhite\fR or \fInone\fR uses white instead of colors for all box backgrounds.
Passing \fIdefault\fR or \fIcolors\fR reverts back to the default color palette.
.TP
\fB\-\-palette\fR type=#rrggbb
Replace the color of the given box type with the given 3x8bit hexadecimal RGB combination (e.g. \fI#ff0000\fR is red).
Existing types are \fImachine\fR, \fIgroup\fR, \fIpackage\fR, \fIgroup_in_package\fR, \fIdie\fR, \fIcore\fR, \fIpu\fR, \fInumanode\fR, \fImemories\fR (box containing multiple memory children), \fIcache\fR, \fIpcidev\fR, \fIosdev\fR, \fIbridge\fR, and \fImisc\fR.
See also CUSTOM COLOR below for customizing individual objects.
.TP
\fB\-\-binding\-color\fR <none|#rrggbb>
Do not colorize PUs and NUMA nodes according to the binding in the graphical output.
Or change the color to the given 3x8bit hexadecimal RGB combination (e.g. \fI#ff0000\fR is red).
.TP
\fB\-\-disallowed\-color\fR <none|#rrggbb>
Do not colorize disallowed PUs and NUMA nodes in the graphical output.
Or change the color to the given 3x8bit hexadecimal RGB combination (e.g. \fI#00ff00\fR is green).
.TP
\fB\-\-top\-color\fR <none|#rrggbb>
Do not colorize task objects in the graphical output when \-\-top is given.
Or change the color to the given 3x8bit hexadecimal RGB combination (e.g. \fI#0000ff\fR is blue).
.TP
\fB\-\-version\fR
Report version and exit.
.TP
\fB\-h\fR \fB\-\-help\fR
Display help message and exit.
.
.\" --shmem-output-addr is undocumented on purpose
.
.\" **************************
.\" Description Section
.\" **************************
.SH DESCRIPTION
.
lstopo and lstopo-no-graphics are capable of displaying a topological map of
the system in a variety of different output formats. The only difference
between lstopo and lstopo-no-graphics is that graphical outputs are only
supported by lstopo, to reduce dependencies on external libraries.
hwloc-ls is identical to lstopo-no-graphics.
.
.PP
The filename specified directly implies the output format that will be
used; see the OUTPUT FORMATS section, below. Output formats that
support color will indicate specific characteristics about individual
CPUs by their color; see the COLORS section, below.
.
.\" **************************
.\" Output Formats Section
.\" **************************
.SH OUTPUT FORMATS
.
.PP
By default, if no output filename is specific, the output is sent
to a graphical window if possible in the current environment
(DISPLAY environment variable set on Unix, etc.).
Otherwise, a text summary is displayed in the console.
The console is also used when the program runs from a terminal
and the output is redirected to a pipe or file.
These default behaviors may be changed by passing \fB\-\-of console\fR
to force console mode or \fB\-\-of window\fR for graphical window.
.
.PP
The filename on the command line usually determines the format of the output.
There are a few filenames that indicate specific output formats and
devices (e.g., a filename of "-" will output a text summary to
stdout), but most filenames indicate the desired output format by
their suffix (e.g., "topo.png" will output a PNG-format file).
.PP
The format of the output may also be changed with "\-\-of".
For instance, "\-\-of pdf" will generate a PDF-format file on the standard
output, while "\-\-of fig toto" will output a Xfig-format file named "toto".
.
.PP
The list of currently supported formats is given below. Any of them may
be used with "\-\-of" or as a filename suffix.
.TP
.B default
Send the output to a window or to the console depending on the environment.
.
.TP
.B window
Send the output to a graphical window.
.
.TP
.B console
Send a text summary to stdout.
Binding or unallowed processors are only annotated in this mode
if verbose; see the COLORS section, below.
.
.TP
.B ascii
Output an ASCII art representation of the map
(formerly called \fBtxt\fR).
If outputting to stdout and if colors are supported on the terminal,
the output will be colorized.
.
.TP
\fBtikz\fR or \fBtex\fR
Output a LaTeX tikzpicture representation of the map that can be
compiled with a LaTeX compiler.
.
.TP
.B fig
Output a representation of the map that can be loaded in Xfig.
.
.TP
.B svg
Output a SVG representation of the map,
using Cairo (by default, if supported)
or a native SVG backend (fallback, always supported).
See \fBcairosvg\fR and \fBnativesvg\fR below.
.
.TP
\fBcairosvg\fR or \fBsvg(cairo)\fR
If lstopo was compiled with the proper support,
output a SVG representation of the map using Cairo.
.
.TP
\fBnativesvg\fR or \fBsvg(native)\fR
Output a SVG representation of the map using the native SVG backend.
It may be less pretty than the Cairo output, but it is always supported,
and SVG objects have attributes for identifying and manipulating them.
See dynamic_SVG_example.html for an example.
.
.TP
.B pdf
If lstopo was compiled with the proper
support, lstopo outputs a PDF representation of the map.
.
.TP
.B ps
If lstopo was compiled with the proper
support, lstopo outputs a Postscript representation of the map.
.
.TP
.B png
If lstopo was compiled with the proper
support, lstopo outputs a PNG representation of the map.
.
.TP
.B synthetic
If the topology is symmetric
(which requires that the root object has its symmetric_subtree field set),
lstopo outputs a synthetic description string.
This output may be reused as an input synthetic topology
description later.
See also the Synthetic topologies section in the documentation.
Note that Misc and I/O devices are ignored during this export.
.
.TP
.B xml
If lstopo was compiled with the proper
support, lstopo outputs an XML representation of the map.
It may be reused later, even on another machine, with lstopo \-\-input,
the HWLOC_XMLFILE environment variable, or the hwloc_topology_set_xml()
function.
.PP
The following special names may be used:
.TP
.B \-
Send a text summary to stdout.
.
.TP
.B /dev/stdout
Send a text summary to stdout. It is effectively the same as
specifying "\-".
.
.TP
.B \-.<format>
If the entire filename is "\-.<format>", lstopo behaves as if
"\-\-of <format> -" was given, which means a file of the given format
is sent to the standard output.
.PP
See the output of "lstopo \-\-help" for a specific list of what
graphical output formats are supported in your hwloc installation.
.
.\" **************************
.\" Graphical Section
.\" **************************
.
.SH GRAPHICAL OUTPUT
The graphical output is made of nested boxes representing
the inclusion of objects in the hierarchy of resources.
Usually a Machine box contains one or several Package boxes,
that contain multiple Core boxes, with one or several PUs each.
.SS Caches
Caches are displayed in a slightly different manner because
they do not actually include computing resources such as cores.
For instance, a L2 Cache shared by a pair of Cores is drawn
as a Cache box on top of two Core boxes
(instead of having Core boxes inside the Cache box).
.SS NUMA nodes and Memory-side Caches
By default, NUMA nodes boxes are drawn on top of their local
computing resources.
For instance, a processor Package containing one NUMA node
and four Cores is displayed as a Package box containing
the NUMA node box above four Core boxes.
If a NUMA node is local to the L3 Cache, the NUMA node is displayed
above that Cache box.
All this specific drawing strategy for memory objects may be disabled
by passing command-line option \fB\-\-children\-order plain\fR.
If multiple NUMA nodes are attached to the same parent object,
they are displayed inside an additional unnamed memory box.
If some Memory-side Caches exist in front of some NUMA nodes,
they are drawn as boxes immediately above them.
.SS PCI bridges, PCI devices and OS devices
The PCI hierarchy is not drawn as a set of included boxes but rather
as a tree of bridges (that may actually be switches) with links between them.
The tree starts with a small square on the left for the
hostbridge or root complex.
It ends with PCI device boxes on the right.
Intermediate PCI bridges/switches may appear as additional small
squares in the middle.
PCI devices on the right of the tree are boxes containing
their PCI bus ID (such as 00:02.3).
They may also contain sub-boxes for OS device objects
such as a network interface \fIeth0\fR or a CUDA GPU \fIcuda0\fR.
When there is a single link (horizontal line) on the right of a
PCI bridge, it means that a single device or bridge is connected
on the secondary PCI bus behind that bridge.
When there is a vertical line, it means that multiple devices
and/or bridges are connected to the same secondary PCI bus.
The datarate of a PCI link may be written (in GB/s) right below
its drawn line (if the operating system and/or libraries are able
to report that information).
This datarate is the currently configured speed of the entire PCI link
(sum of the bandwidth of all PCI lanes in that link).
It may change during execution since some devices are able to
slow their PCI links down when idle.
.
.\" **************************
.\" Layout Section
.\" **************************
.SH LAYOUT
In its graphical output, lstopo uses simple rectangular heuristics
to try to achieve a 4/3 ratio between width and height.
Although the hierarchy of resources is properly reflected,
the exact physical organization (NUMA distances, rings,
complete graphs, etc.) is currently ignored.
The layout of a level may be changed with \fB\-\-vert\fR, \fB\-\-horiz\fR,
and \fB\-\-rect\fR to force a parent object to arrange its children
in vertical, horizontal or rectangular manners respectively.
The position of Memory, I/O and Misc children with respect to other
children objects may be changed using \fB\-\-children\-order\fR.
This effectivement divides children into multiple sections.
The layout of children is first computed inside each section,
before sections are placed inside (or below) the parent box.
The vertical/horizontal/rectangular layout of these additional
sections may also be configured through \fB\-\-children\-order\fR.
.
.\" **************************
.\" Colors Section
.\" **************************
.SH COLORS
Individual CPUs and NUMA nodes are colored in the graphical output
formats to indicate different characteristics:
.TP
Green
The topology is reported as seen by a specific process (see \fB\-\-pid\fR),
and the given CPU or NUMA node is in this process CPU or Memory binding mask.
.TP
White
The CPU or NUMA node is in the allowed set (see below).
If the topology is reported as seen by a specific process (see \fB\-\-pid\fR),
the object is also not in this process binding mask.
.TP
Red
The CPU or NUMA node is not in the allowed set (see below).
.
.PP
The "allowed set" is the set of CPUs or NUMA nodes to which the current process is
allowed to bind. The allowed set is usually either inherited from the
parent process or set by administrative qpolicies on the system. Linux
cpusets are one example of limiting the allowed set for a process and
its children to be less than the full set of CPUs or NUMA nodes on the system.
.PP
Different processes may therefore have different CPUs or NUMA nodes in the allowed
set. Hence, invoking lstopo in different contexts and/or as different
users may display different colors for the same individual CPUs (e.g.,
running lstopo in one context may show a specific CPU as red, but
running lstopo in a different context may show the same CPU as white).
.PP
Some lstopo output modes, e.g. the console mode (default non-graphical output),
do not support colors at all.
The console mode displays the above characteristics by appending text
to each PU line if verbose messages are enabled.
.
.SH CUSTOM COLORS
The colors of different kinds of boxes may be configured with \fB\-\-palette\fR.
The color of each object in the graphical output may also be enforced by
specifying a "lstopoStyle" info attribute in that object.
Its value should be a semi-colon separated list of "<attribute>=#rrggbb"
where rr, gg and bb are the RGB components of a color,
each between 0 and 255, in hexadecimal (00 to ff).
.
<attribute> may be
.TP
\fBBackground\fR
Sets the background color of the main object box.
.TP
\fBText\fR
Sets the color of the text showing the object name, type, index, etc.
.TP
\fBText2\fB
Sets the color of the additional text near the object,
for instance the link speed behind a PCI bridge.
.PP
The "lstopoStyle" info may be added to a temporarily-saved XML topologies
with hwloc-annotate, or with hwloc_obj_add_info().
.
For instance, to display all core objects in blue (with white names):
lstopo save.xml
hwloc-annotate save.xml save.xml core:all info lstopoStyle "Background=#0000ff;Text=#ffffff"
lstopo -i save.xml
.
.\" **************************
.\" Examples Section
.\" **************************
.SH EXAMPLES
.
To display the machine topology in textual mode:
lstopo-no-graphics
To display the machine topology in ascii-art mode:
lstopo-no-graphics -.ascii
To display in graphical mode (assuming that the DISPLAY environment
variable is set to a relevant value):
lstopo
To export the topology to a PNG file:
lstopo file.png
To export an XML file on a machine and later display the corresponding
graphical output on another machine:
machine1$ lstopo file.xml
<transfer file.xml from machine1 to machine2>
machine2$ lstopo --input file.xml
To save the current machine topology to XML and later reload it faster
while still considering it as the current machine:
$ lstopo file.xml
<...>
$ lstopo --input file.xml --thissystem
To restrict an XML topology to only physical processors 0, 1, 4 and 5:
lstopo --input file.xml --restrict 0x33 newfile.xml
To restrict an XML topology to only numa node whose logical index is 1:
lstopo --input file.xml --restrict $(hwloc-calc --input file.xml node:1) newfile.xml
To display a summary of the topology:
lstopo -s
To get more details about the topology:
lstopo -v
To only show cores:
lstopo --only core
To show cpusets:
lstopo --cpuset
To only show the cpusets of package:
lstopo --only package --cpuset-only
Simulate a fake hierarchy; this example shows with 2 NUMA nodes of 2
processor units:
lstopo --input "node:2 2"
To count the number of logical processors in the system
lstopo --only pu | wc -l
To append the kernel release and version to the graphical legend:
lstopo --append-legend "Kernel release: $(uname -r)" --append-legend "Kernel version: $(uname -v)"
.
.\" **************************
.\" Notes Section
.\" **************************
.SH NOTES
.
lstopo displays memory and cache sizes with units such as
\fBkB\fR (1 kilobyte = 1000 bytes) or \fBGB\fR (1 gigabyte = 1000*1000*1000 bytes)
while it actually means
\fBKiB\fR (1 kibibyte = 1024 bytes) or \fBGiB\fR (1 gibibytes = 1024*1024*1024 bytes) .
.
.\" **************************
.\" See also section
.\" **************************
.SH SEE ALSO
.
.ft R
hwloc(7), hwloc-info(1), hwloc-bind(1), hwloc-annotate(1), hwloc-ps(1), hwloc-gather-topology(1), hwloc-gather-cpuid(1)
.sp
@@ -1 +0,0 @@
.so man3/hwlocality_tinker.3
@@ -1 +0,0 @@
.so man3/hwlocality_tinker.3
@@ -1 +0,0 @@
.so man3/hwlocality_tinker.3
@@ -1 +0,0 @@
.so man3/hwlocality_api_version.3
@@ -1 +0,0 @@
.so man3/hwlocality_cpubinding.3
@@ -1 +0,0 @@
.so man3/hwlocality_cpubinding.3
@@ -1 +0,0 @@
.so man3/hwlocality_cpubinding.3
@@ -1 +0,0 @@
.so man3/hwlocality_cpubinding.3
@@ -1 +0,0 @@
.so man3/hwlocality_distances_add.3
@@ -1 +0,0 @@
.so man3/hwlocality_distances_add.3
@@ -1 +0,0 @@
.so man3/hwlocality_distances_get.3
@@ -1 +0,0 @@
.so man3/hwlocality_distances_get.3
@@ -1 +0,0 @@
.so man3/hwlocality_distances_get.3
@@ -1 +0,0 @@
.so man3/hwlocality_distances_get.3
@@ -1 +0,0 @@
.so man3/hwlocality_distances_get.3
@@ -1 +0,0 @@
.so man3/hwlocality_distances_get.3
@@ -1 +0,0 @@
.so man3/hwlocality_distances_get.3
@@ -1 +0,0 @@
.so man3/hwlocality_distances_get.3
@@ -1 +0,0 @@
.so man3/hwlocality_helper_distribute.3
@@ -1 +0,0 @@
.so man3/hwlocality_memattrs.3
@@ -1 +0,0 @@
.so man3/hwlocality_memattrs.3
@@ -1 +0,0 @@
.so man3/hwlocality_memattrs.3
@@ -1 +0,0 @@
.so man3/hwlocality_memattrs.3
@@ -1 +0,0 @@
.so man3/hwlocality_memattrs.3
@@ -1 +0,0 @@
.so man3/hwlocality_memattrs_manage.3
@@ -1 +0,0 @@
.so man3/hwlocality_memattrs_manage.3
@@ -1 +0,0 @@
.so man3/hwlocality_memattrs_manage.3
@@ -1 +0,0 @@
.so man3/hwlocality_memattrs.3
@@ -1 +0,0 @@
.so man3/hwlocality_memattrs.3
@@ -1 +0,0 @@
.so man3/hwlocality_memattrs.3
@@ -1 +0,0 @@
.so man3/hwlocality_memattrs.3
@@ -1 +0,0 @@
.so man3/hwlocality_membinding.3
@@ -1 +0,0 @@
.so man3/hwlocality_membinding.3
@@ -1 +0,0 @@
.so man3/hwlocality_membinding.3
@@ -1 +0,0 @@
.so man3/hwlocality_membinding.3
@@ -1 +0,0 @@
.so man3/hwlocality_membinding.3
@@ -1 +0,0 @@
.so man3/hwlocality_membinding.3
@@ -1 +0,0 @@
.so man3/hwlocality_membinding.3
@@ -1 +0,0 @@
.so man3/hwlocality_membinding.3
@@ -1 +0,0 @@
.so man3/hwlocality_membinding.3
@@ -1 +0,0 @@
.so man3/hwlocality_membinding.3
@@ -1 +0,0 @@
.so man3/hwlocality_membinding.3
@@ -1 +0,0 @@
.so man3/hwlocality_membinding.3
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
-1
View File
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
-1
View File
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
-1
View File
@@ -1 +0,0 @@
.so man3/hwlocality_object_types.3
@@ -1 +0,0 @@
.so man3/hwlocality_tinker.3

Some files were not shown because too many files have changed in this diff Show More