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
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://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.8.8"/>
<title>Hardware Locality (hwloc): Synthetic topologies</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 style="padding-left: 0.5em;">
<div id="projectname">Hardware Locality (hwloc)
 <span id="projectnumber">1.10.0</span>
</div>
</td>
</tr>
</tbody>
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.8.8 -->
<div id="navrow1" class="tabs">
<ul class="tablist">
<li><a href="index.html"><span>Main Page</span></a></li>
<li class="current"><a href="pages.html"><span>Related Pages</span></a></li>
<li><a href="modules.html"><span>Modules</span></a></li>
<li><a href="annotated.html"><span>Data Structures</span></a></li>
</ul>
</div>
</div><!-- top -->
<div class="header">
<div class="headertitle">
<div class="title">Synthetic topologies </div> </div>
</div><!--header-->
<div class="contents">
<div class="textblock"><p>hwloc may load fake or remote topologies so as to consult them without having the underlying hardware available. Aside from loading XML topologies, hwloc also enables the building of <em>synthetic</em> topologies that are described by a single string listing the arity of each levels.</p>
<p>For instance, lstopo may create a topology made of 2 NUMA nodes, containing a single socket each, with one cache above two single-threaded cores:</p>
<pre class="fragment">$ lstopo -i "node:2 sock:1 cache:1 core:2 pu:1" -
Machine (2048MB)
NUMANode L#0 (P#0 1024MB) + Socket L#0 + L2 L#0 (4096KB)
Core L#0 + PU L#0 (P#0)
Core L#1 + PU L#1 (P#1)
NUMANode L#1 (P#1 1024MB) + Socket L#1 + L2 L#1 (4096KB)
Core L#2 + PU L#2 (P#2)
Core L#3 + PU L#3 (P#3)
</pre><p>Replacing <code>-</code> with <code>file.xml</code> in this command line will export this topology to XML as usual.</p>
<dl class="section note"><dt>Note</dt><dd>Synthetic topologies offer a very basic way to export a topology and reimport it on another machine. It is a lot less precise than XML but may still be enough when only the hierarchy of resources matters.</dd></dl>
<h1><a class="anchor" id="synthetic_string"></a>
Synthetic description string</h1>
<p>Each item in the description string gives the type of the level and the number of such children under each object of the previous level. That is why the above topology contains 4 cores (2 cores times 2 nodes).</p>
<p>These type names must be written as <code>machine</code>, <code>node</code>, <code>socket</code>, <code>core</code>, <code>cache</code>, <code>pu</code>, <code>misc</code>, <code>group</code>. They do not need to be written case-sensitively, nor entirely (as long as there is no ambiguity, 2 characters such as <code>ma</code> select a Machine level). Type-specific attributes may also be given such as <code>L2iCache</code> (<a class="el" href="a00079.html#ga8f8452fa8e707cad59b8a73a6fa06059" title="Return an object type and attributes from a type string. ">hwloc_obj_type_sscanf()</a> is used for parsing the type names). Note that I/O objects are not available.</p>
<p>The root object does not appear in the string. A Machine object is used by default, and a System object replaces it if a Machine level is specified in the string.</p>
<p>Cache level depths are automatically chosen by hwloc (only a L2 first, then a L1 under it, then L3 above, then L4 etc.) unless they are specified. Memory and cache sizes are also automatically chosen. The only way to modifying them is to export to XML and manually modify the file.</p>
<p>Each item may be followed parentheses containing a list of space-separated attributes. For instance: </p><ul>
<li>
<code>L2iCache:2(size=32768)</code> specifies 2 children of 32kB level-2 instruction caches. </li>
<li>
<code>NUMANode:3(memory=16777216)</code> specifies 3 NUMA nodes with 16MB each. </li>
<li>
<code>PU:2(indexes=0,2,1,3)</code> specifies 2 PU children and the full list of OS indexes among the entire set of 4 PU objects. </li>
<li>
<code>PU:2(indexes=numa:core)</code> specifies 2 PU children whose OS indexes are interleaved by NUMA node first and then by socket. </li>
<li>
Attributes in parentheses at the very beginning of the description apply to the root object. </li>
</ul>
<h1><a class="anchor" id="synthetic_use"></a>
Loading a synthetic topology</h1>
<p>Aside from lstopo, the hwloc programming interface offers the same ability by passing the synthetic description string to <a class="el" href="a00077.html#ga4fab186bb6181a00bcf585825fddd38d" title="Enable synthetic topology. ">hwloc_topology_set_synthetic()</a> before <a class="el" href="a00076.html#gabdf58d87ad77f6615fccdfe0535ff826" title="Build the actual topology. ">hwloc_topology_load()</a>.</p>
<p>Synthetic topologies are created by the <code>synthetic</code> component. This component may be enabled by force by setting the HWLOC_COMPONENTS environment variable to something such as <code>synthetic="node:2 core:3 pu:4"</code>.</p>
<p>Loading a synthetic topology disables binding support since the topology usually does not match the underlying hardware. Binding may be reenabled as usual by setting HWLOC_THISSYSTEM=1 in the environment or by setting the HWLOC_TOPOLOGY_FLAG_IS_THISSYSTEM topology flag.</p>
<h1><a class="anchor" id="synthetic_export"></a>
Exporting a topology as a synthetic string</h1>
<p>The function <a class="el" href="a00085.html#ga24b7864a1c588309c4749f621f03b4c7" title="Export the topology as a synthetic string. ">hwloc_topology_export_synthetic()</a> may export a topology as a synthetic string. It offers a convenient way to quickly describe the contents of a machine. The lstopo tool may also perform such an export by forcing the output format.</p>
<pre class="fragment">$ lstopo --of synthetic --no-io
Socket:1 Cache:1 Cache:2 Cache:1 Cache:1 Core:1 PU:2
</pre><p>The exported string may be passed back to hwloc for recreating another similar topology. The entire tree will be similar, but some special attributes such processort types may be missing.</p>
<p>Such an export is only possible if the topology is totally symmetric, which means the <code>symmetric_subtree</code> field of the root object is set. This usually implies that I/O objects are disabled since attaching I/O busses often cause the topology to become asymmetric. Passing <code>–no-io</code> to lstopo is therefore often useful to make synthetic export work (as well as not passing any I/O topology flag before exporting with <a class="el" href="a00085.html#ga24b7864a1c588309c4749f621f03b4c7" title="Export the topology as a synthetic string. ">hwloc_topology_export_synthetic()</a>). </p>
</div></div><!-- contents -->
<!-- start footer part -->
<hr class="footer"/><address class="footer"><small>
Generated on Tue Oct 7 2014 11:56:52 for Hardware Locality (hwloc) by  <a href="http://www.doxygen.org/index.html">
<img class="footer" src="doxygen.png" alt="doxygen"/>
</a> 1.8.8
</small></address>
</body>
</html>
|
