1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
<meta name="generator" content="Doxygen 1.9.1"/>
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<title>Hardware Locality (hwloc): Components and plugins</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<link href="doxygen.css" rel="stylesheet" type="text/css" />
</head>
<body>
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
<tbody>
<tr style="height: 56px;">
<td id="projectalign" style="padding-left: 0.5em;">
<div id="projectname">Hardware Locality (hwloc)
 <span id="projectnumber">2.4.1</span>
</div>
</td>
</tr>
</tbody>
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.9.1 -->
<script type="text/javascript" src="menudata.js"></script>
<script type="text/javascript" src="menu.js"></script>
<script type="text/javascript">
/* @license magnet:?xt=urn:btih:cf05388f2679ee054f2beb29a391d25f4e673ac3&dn=gpl-2.0.txt GPL-v2 */
$(function() {
initMenu('',false,false,'search.php','Search');
});
/* @license-end */</script>
<div id="main-nav"></div>
</div><!-- top -->
<div class="PageDoc"><div class="header">
<div class="headertitle">
<div class="title">Components and plugins </div> </div>
</div><!--header-->
<div class="contents">
<div class="textblock"><p>
<div class="section">
</p>
<p>hwloc is organized in components that are responsible for discovering objects. Depending on the topology configuration, some components will be used, some will be ignored. The usual default is to enable the native operating system component, (e.g. <code>linux</code> or <code>solaris</code>) and the <code>pci</code> miscellaneous component. If available, an architecture-specific component (such as <code>x86</code>) may also improve the topology detection.</p>
<p>If a XML topology is loaded, the <code>xml</code> discovery component will be used instead of all other components. It internally uses a specific class of components for the actual XML import/export routines (<code>xml_libxml</code> and <code>xml_nolibxml</code>) but these will not be discussed here (see <a class="el" href="a00394.html#xml_backends">libxml2 and minimalistic XML backends</a>).</p>
<p>
</div><div class="section" id="plugins_default">
</p>
<h1><a class="anchor" id="plugins_default"></a>
Components enabled by default</h1>
<p>The hwloc core contains a list of components sorted by priority. Each one is enabled as long as it does not conflict with the previously enabled ones. This includes native operating system components, architecture-specific ones, and if available, I/O components such as <code>pci</code>.</p>
<p>Usually the native operating system component (when it exists, e.g. <code>linux</code> or <code>aix</code>) is enabled first. Then hwloc looks for an architecture specific component (e.g. <code>x86</code>). Finally there also exist a basic component (<code>no_os</code>) that just tries to discover the number of PUs in the system.</p>
<p>Each component discovers as much topology information as possible. Most of them, including most native OS components, do nothing unless the topology is still empty. Some others, such as <code>x86</code> and <code>pci</code>, can complete and annotate what other backends found earlier. Discovery is performed by phases: CPUs are first discovered, then memory is attached, then PCI, etc.</p>
<p>Default priorities ensure that clever components are invoked first. Native operating system components have higher priorities, and are therefore invoked first, because they likely offer very detailed topology information. If needed, it will be later extended by architecture-specific information (e.g. from the <code>x86</code> component).</p>
<p>If any configuration function such as <a class="el" href="a00198.html#ga879439b7ee99407ee911b3ac64e9a25e" title="Enable XML-file based topology.">hwloc_topology_set_xml()</a> is used before loading the topology, the corresponding component is enabled first. Then, as usual, hwloc enables any other component (based on priorities) that does not conflict.</p>
<p>Certain components that manage a virtual topology, for instance XML topology import or synthetic topology description, conflict with all other components. Therefore, one of them may only be loaded (e.g. with <code><a class="el" href="a00198.html#ga879439b7ee99407ee911b3ac64e9a25e" title="Enable XML-file based topology.">hwloc_topology_set_xml()</a></code>) if no other component is enabled.</p>
<p>The environment variable <code>HWLOC_COMPONENTS_VERBOSE</code> may be set to get verbose messages about component registration (including their priority) and enabling.</p>
<p>
</div><div class="section" id="plugins_select">
</p>
<h1><a class="anchor" id="plugins_select"></a>
Selecting which components to use</h1>
<p>If no topology configuration functions such as <code><a class="el" href="a00198.html#ga4fab186bb6181a00bcf585825fddd38d" title="Enable synthetic topology.">hwloc_topology_set_synthetic()</a></code> have been called, plugins may be selected with environment variables such as <code>HWLOC_XMLFILE</code>, <code>HWLOC_SYNTHETIC</code>, <code>HWLOC_FSROOT</code>, or <code>HWLOC_CPUID_PATH</code> (see <a class="el" href="a00388.html">Environment Variables</a>).</p>
<p>Finally, the environment variable <code>HWLOC_COMPONENTS</code> resets the list of selected components. If the variable is set and empty (or set to a single comma separating nothing, since some operating systems do not accept empty variables), the normal plugin priority order is used.</p>
<p>If the variable is set to <code>x86</code> in this variable will cause the <code>x86</code> component to take precedence over any other component, including the native operating system component. It is therefore loaded first, before hwloc tries to load all remaining non-conflicting components. In this case, <code>x86</code> would take care of discovering everything it supports, instead of only completing what the native OS information. This may be useful if the native component is buggy on some platforms.</p>
<p>It is possible to prevent some components from being loaded by prefixing their name with <code>-</code> in the list. For instance <code>x86,-pci</code> will load the <code>x86</code> component, then let hwloc load all the usual components except <code>pci</code>. A single component phase may also be blacklisted, for instance with <code>-linux:io</code>. <a class="el" href="a00198.html#ga9ad41adf418cee1c0ee32ba9bd4a3d36" title="Prevent a discovery component from being used for a topology.">hwloc_topology_set_components()</a> may also be used inside the program to prevent the loading of a specific component (or phases) for the target topology.</p>
<p>It is possible to prevent all remaining components from being loaded by placing <code>stop</code> in the environment variable. Only the components listed before this keyword will be enabled.</p>
<p>
</div><div class="section" id="plugins_load">
</p>
<h1><a class="anchor" id="plugins_load"></a>
Loading components from plugins</h1>
<p>Components may optionally be built as plugins so that the hwloc core library does not directly depend on their dependencies (for instance the <code>libpciaccess</code> library). Plugin support may be enabled with the <code>--enable-plugins</code> configure option. All components buildable as plugins will then be built as plugins. The configure option may be given a comma-separated list of component names to specify the exact list of components to build as plugins.</p>
<p>Plugins are built as independent dynamic libraries that are installed in <code>$libdir/hwloc</code>. All plugins found in this directory are loaded during <code>topology_init()</code> (unless blacklisted in <code>HWLOC_PLUGINS_BLACKLIST</code>, see <a class="el" href="a00388.html">Environment Variables</a>). A specific list of directories (colon-separated) to scan may be specified in the <code>HWLOC_PLUGINS_PATH</code> environment variable.</p>
<p>Note that loading a plugin just means that the corresponding component is registered to the hwloc core. Components are then only enabled if the topology configuration requests it, as explained in the previous sections.</p>
<p>Also note that plugins should carefully be enabled and used when embedding hwloc in another project, see <a class="el" href="a00399.html">Embedding hwloc in Other Software</a> for details.</p>
<p>
</div><div class="section" id="plugins_list">
</p>
<h1><a class="anchor" id="plugins_list"></a>
Existing components and plugins</h1>
<p>All components distributed within hwloc are listed below. The list of actually available components may be listed at running with the <code>HWLOC_COMPONENTS_VERBOSE</code> environment variable (see <a class="el" href="a00388.html">Environment Variables</a>).</p>
<dl>
<dt>linux </dt>
<dd>The official component for discovering CPU, memory and I/O devices on Linux. It discovers PCI devices without the help of external libraries such as libpciaccess, but requires the pci component for adding vendor/device names to PCI objects. It also discovers many kinds of Linux-specific OS devices. </dd>
<dt>aix, darwin, freebsd, hpux, netbsd, solaris, windows </dt>
<dd>Each officially supported operating system has its own native component, which is statically built when supported, and which is used by default. </dd>
<dt>x86 </dt>
<dd>The x86 architecture (either 32 or 64 bits) has its own component that may complete or replace the previously-found CPU information. It is statically built when supported. </dd>
<dt>bgq </dt>
<dd>This component is specific to IBM BlueGene/Q compute node (running CNK). It is built and enabled by default when <code>--host=powerpc64-bgq-linux</code> is passed to configure (see <a class="el" href="a00400.html#faq_bgq">How do I build hwloc for BlueGene/Q?</a>). </dd>
<dt>no_os </dt>
<dd>A basic component that just tries to detect the number of processing units in the system. It mostly serves on operating systems that are not natively supported. It is always statically built. </dd>
<dt>pci </dt>
<dd>PCI object discovery uses the external pciaccess library (aka libpciaccess); see <a class="el" href="a00390.html">I/O Devices</a>. It may also annotate existing PCI devices with vendor and device names. <b>It may be built as a plugin</b>. </dd>
<dt>opencl </dt>
<dd>The OpenCL component creates co-processor OS device objects such as <em>opencl0d0</em> (first device of the first OpenCL platform) or <em>opencl1d3</em> (fourth device of the second platform). Only the AMD and NVIDIA OpenCL implementations currently offer locality information. <b>It may be built as a plugin</b>. </dd>
<dt>rsmi </dt>
<dd>This component creates GPU OS device objects such as <em>rsmi0</em> for describing AMD GPUs. <b>It may be built as a plugin</b>. </dd>
<dt>cuda </dt>
<dd>This component creates co-processor OS device objects such as <em>cuda0</em> that correspond to NVIDIA GPUs used with CUDA library. <b>It may be built as a plugin</b>. </dd>
<dt>nvml </dt>
<dd>Probing the NVIDIA Management Library creates OS device objects such as <em>nvml0</em> that are useful for batch schedulers. It also detects the actual PCIe link bandwidth without depending on power management state and without requiring administrator privileges. <b>It may be built as a plugin</b>. </dd>
<dt>gl </dt>
<dd>Probing the NV-CONTROL X extension (NVCtrl library) creates OS device objects such as <em>:0.0</em> corresponding to NVIDIA displays. They are useful for graphical applications that need to place computation and/or data near a rendering GPU. <b>It may be built as a plugin</b>. </dd>
<dt>synthetic </dt>
<dd>Synthetic topology support (see <a class="el" href="a00395.html">Synthetic topologies</a>) is always built statically. </dd>
<dt>xml </dt>
<dd>XML topology import (see <a class="el" href="a00394.html">Importing and exporting topologies from/to XML files</a>) is always built statically. It internally uses one of the XML backends (see <a class="el" href="a00394.html#xml_backends">libxml2 and minimalistic XML backends</a>). <ul>
<li>
<b>xml_nolibxml</b> is a basic and hwloc-specific XML import/export. It is always statically built. </li>
<li>
<b>xml_libxml</b> relies on the external libxml2 library for provinding a feature-complete XML import/export. <b>It may be built as a plugin</b>. </li>
</ul>
</dd>
<dt>fake </dt>
<dd>A dummy plugin that does nothing but is used for debugging plugin support. </dd>
</dl>
</div></div><!-- contents -->
</div><!-- PageDoc -->
<!-- start footer part -->
<hr class="footer"/><address class="footer"><small>
Generated by <a href="https://www.doxygen.org/index.html"><img class="footer" src="doxygen.svg" width="104" height="31" alt="doxygen"/></a> 1.9.1
</small></address>
</body>
</html>
|
