AMD Radeon™ GPU Profiler
AMD RGP 让您能够前所未有地深入了解 GPU。轻松分析图形、异步计算使用情况、事件计时、管线停顿、屏障、瓶颈和其他性能低效之处。
在 Affinity 系列博客的第一部分中，我们讨论了为高性能计算 (HPC) 工作负载设置 Affinity 的重要性。在本篇博客文章中，我们的目标如下：
-
介绍可帮助您了解系统拓扑的工具
-
讨论验证 Affinity 是否已正确设置以供运行的方法
-
展示如何为不同类型的应用程序设置 Affinity
请注意，此处提供的这些工具和技术可能不适用于您的系统。这可能是由于消息传递接口 (MPI) 实现或内核版本不同，或是新的系统配置。这些说明旨在作为参考，我们希望您能从中吸取思想并在您的系统设置中应用。
了解系统拓扑
在异构系统中，我们拥有 CPU、GPU、内存控制器、NIC 等不同类型的资源。有许多工具可用于逐步了解您系统上的非统一内存访问 (NUMA) 配置。在本节中，我们将展示工具示例以及它们可以为我们提供的信息。
CPU 信息 – lscpu
lscpu 工具是 Linux® 发行版的一部分，可用于以易于阅读的文本格式显示 CPU 架构信息。下面显示了 lscpu 输出的一个片段。一些关键项目值得注意，包括系统上的插槽数、每个插槽的物理核心数、每个物理核心上的硬件线程 (HWT) 数以及系统中配置的 NUMA 域。在每个 NUMA 域旁边，列出了属于该域的物理核心和 HWT。在这种情况下，有 2 个插槽和 8 个 NUMA 域，这表示 NPS4 配置。前 4 个 NUMA 域位于插槽 0 中，接下来的 4 个 NUMA 域位于插槽 1 中。
Thread(s) per core: 2Core(s) per socket: 64Socket(s): 2NUMA node(s): 8NUMA node0 CPU(s): 0-15,128-143NUMA node1 CPU(s): 16-31,144-159NUMA node2 CPU(s): 32-47,160-175NUMA node3 CPU(s): 48-63,176-191NUMA node4 CPU(s): 64-79,192-207NUMA node5 CPU(s): 80-95,208-223NUMA node6 CPU(s): 96-111,224-239NUMA node7 CPU(s): 112-127,240-255CPU NUMA 配置 – numactl
numactl 工具是 Linux 发行版的一部分，可用于控制进程或共享内存的 NUMA 策略。它还可用于显示有关哪些 CPU 核心或 HWT 属于每个 NUMA 域的信息。下面显示了 numactl -H 输出的一个样本。在此处，请注意不同插槽中的 NUMA 域之间的距离更大。
numactl -Havailable: 8 nodes (0-7)node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143node 0 size: 64306 MBnode 0 free: 59767 MBnode 1 cpus: 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159node 1 size: 64502 MBnode 1 free: 61327 MBnode 2 cpus: 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175node 2 size: 64502 MBnode 2 free: 61605 MBnode 3 cpus: 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191node 3 size: 64447 MBnode 3 free: 61272 MBnode 4 cpus: 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207node 4 size: 64502 MBnode 4 free: 52763 MBnode 5 cpus: 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223node 5 size: 64502 MBnode 5 free: 54458 MBnode 6 cpus: 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239node 6 size: 64502 MBnode 6 free: 57521 MBnode 7 cpus: 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255node 7 size: 64492 MBnode 7 free: 55638 MBnode distances:node 0 1 2 3 4 5 6 7 0: 10 12 12 12 32 32 32 32 1: 12 10 12 12 32 32 32 32 2: 12 12 10 12 32 32 32 32 3: 12 12 12 10 32 32 32 32 4: 32 32 32 32 10 12 12 12 5: 32 32 32 32 12 10 12 12 6: 32 32 32 32 12 12 10 12 7: 32 32 32 32 12 12 12 10GPU 信息 – rocm-smi
rocm-smi 工具作为 ROCm™ 堆栈的一部分分发。rocm-smi 可用于显示有关系统中 GPU 的详细信息。请看下面的 rocm-smi 输出。它显示系统中共有 8 个 AMD Instinct™ MI210 GPU。
====================================== ROCm System Management Interface ====================================================================================== Concise Info ================================================Device [Model : Revision] Temp Power Partitions SCLK MCLK Fan Perf PwrCap VRAM% GPU% Name (20 chars) (Edge) (Avg) (Mem, Compute)==============================================================================================================0 [0x0c34 : 0x02] 34.0°C 43.0W N/A, N/A 800Mhz 1600Mhz 0% auto 300.0W 0% 0% Instinct MI2101 [0x0c34 : 0x02] 39.0°C 42.0W N/A, N/A 800Mhz 1600Mhz 0% auto 300.0W 0% 0% Instinct MI2102 [0x0c34 : 0x02] 33.0°C 41.0W N/A, N/A 800Mhz 1600Mhz 0% auto 300.0W 0% 0% Instinct MI2103 [0x0c34 : 0x02] 38.0°C 42.0W N/A, N/A 800Mhz 1600Mhz 0% auto 300.0W 0% 0% Instinct MI2104 [0x0c34 : 0x02] 33.0°C 43.0W N/A, N/A 800Mhz 1600Mhz 0% auto 300.0W 0% 0% Instinct MI2105 [0x0c34 : 0x02] 35.0°C 42.0W N/A, N/A 800Mhz 1600Mhz 0% auto 300.0W 0% 0% Instinct MI2106 [0x0c34 : 0x02] 33.0°C 40.0W N/A, N/A 800Mhz 1600Mhz 0% auto 300.0W 0% 0% Instinct MI2107 [0x0c34 : 0x02] 39.0°C 42.0W N/A, N/A 800Mhz 1600Mhz 0% auto 300.0W 0% 0% Instinct MI210========================================================================================================================================================== End of ROCm SMI Log =============================================GPU NUMA 配置 – rocm-smi —showtoponuma
rocm-smi —showtoponuma 有助于了解每个 GPU 的 NUMA 绑定。例如，我们在此看到 GPU 0 最接近 NUMA 节点 3，从 lscpu 或 numactl 的输出中，我们知道 NUMA 节点 3 包含 CPU 核心/HWT 48-63,176-191。因此，在此系统上，最好在核心 48 上运行使用 GPU 0 的进程。
============================ ROCm System Management Interface =================================================================== Numa Nodes =======================================GPU[0] : (Topology) Numa Node: 3GPU[0] : (Topology) Numa Affinity: 3GPU[1] : (Topology) Numa Node: 2GPU[1] : (Topology) Numa Affinity: 2GPU[2] : (Topology) Numa Node: 1GPU[2] : (Topology) Numa Affinity: 1GPU[3] : (Topology) Numa Node: 0GPU[3] : (Topology) Numa Affinity: 0GPU[4] : (Topology) Numa Node: 7GPU[4] : (Topology) Numa Affinity: 7GPU[5] : (Topology) Numa Node: 6GPU[5] : (Topology) Numa Affinity: 6GPU[6] : (Topology) Numa Node: 5GPU[6] : (Topology) Numa Affinity: 5GPU[7] : (Topology) Numa Node: 4GPU[7] : (Topology) Numa Affinity: 4================================== End of ROCm SMI Log ===================================节点拓扑 – lstopo
lstopo 是 Linux 上 hwloc 包的一部分，可用于以各种输出格式显示系统拓扑。下图中，我们看到了代表节点上两个插槽的两个包。每个包有 4 个 NUMA 域。
将视图放大到 NUMA 节点 1，如下图所示，我们看到它有 16 个 CPU 核心，每个核心有 2 个 HWT，以及一个通过 PCIe 接口连接的 GPU。请注意，8 个物理核心共享一个 L3 缓存。将同一进程的线程放在同一个 L3 缓存区域附近，如果所有这些线程读取的数据都适合缓存，则可以提高缓存的重用率。
验证 Affinity 设置
在测量性能之前，检查 Affinity 设置是否正确始终是个好主意。以下是一些您可以执行的操作列表：
-
查看
top或htop可以告诉我们进程及其线程正在运行的 CPU HWT。 -
如果使用 OpenMPI，可以使用
mpirun —report-bindings来显示每个 rank 可能放置的核心选择。 -
对于 MPI + OpenMP® 程序，您可以使用来自橡树岭国家实验室领导计算设施 (OLCF) 的以下简单的“Hello, World”程序来检查映射：hello_mpi_omp
-
对于 MPI + OpenMP + HIP 程序，可以使用来自 OLCF 的简单的 HIP “Hello, World”程序来验证映射：hello_jobstep
-
Bob Robey 的书《Essentials of Parallel Computing》第 14 章中的示例代码可用于验证 OpenMP、MPI 和 MPI+OpenMP 情况的映射。
在使用 Slurm 批处理命令运行作业时，最好在提交您的作业之前，使用相同的 slurm 配置运行上述一个 hello world 程序，以验证 Affinity 设置。
设置 Affinity
简单来说，设置 Affinity 意味着为本次运行选择要使用的 CPU 核心、GPU(s) 和/或其他资源。对于不同的场景，Affinity 设置可能不同。识别不同情况并应用正确的方法是关键。在以下各节中，针对不同情况展示了一组代表性的技术。请注意，这些工具中的每一个可能都提供更多您可以利用的功能，以适应您的用例。由于功能经常更改，因此最好查阅相应工具的 man 页。
串行，单线程应用程序
如果您的应用程序仅在单个 CPU 核心上运行，那么固定进程的快速方法是使用基于 Linux 的 numactl 工具。以下是一个简单的示例，指示 OS 该进程可以调度在核心 1 或 2 上。
numactl -C 1,2 ./exe提示： 由于核心 0 可能被 OS 用于服务中断和其他系统活动，因此最好避免使用它以减少运行中的变异性。
在下面的示例中，我们要求该进程的所有内存仅分配在 NUMA 节点 0 上。
numactl -C 1,2 -m 0 ./exe串行，多线程应用程序
在本节中，我们考虑使用 Pthreads 或 OpenMP 的多线程应用程序，以及可用于为这些应用程序设置 Affinity 的一些工具。
为基于 Pthreads 的应用程序设置 Affinity
numactl 可用于固定进程及其线程，方法是提供要绑定到的核心范围。在下面的示例中，我们要求在核心 1-7 上运行可执行文件，并将所有内存分配交错在 NUMA 节点 0 和 1 中。
numactl -C 1-7 -i 0,1 ./exe为基于 OpenMP 的应用程序设置 Affinity
虽然 numactl 可用于使用 Pthreads 或 OpenMP 构建的多线程应用程序，但 OpenMP 5.2 标准指定了可以组合使用并用于控制基于 OpenMP 的多线程应用程序的 Affinity 的环境变量。下面给出了某些关键环境变量的描述。
-
OMP_PLACES指示用于放置进程及其线程的硬件资源。一些示例包括实现依赖的抽象名称，如cores、threads、sockets、L3CACHE或NUMA，或者由非负数描述的显式位置列表。考虑以下示例：-
export OMP_PLACES=threads表示每个位置是一个硬件线程 (HWT) -
export OMP_PLACES={0,1}以在核心 0 和 1 上运行进程及其线程 -
export OMP_PLACES={0:OMP_NUM_THREADS:2}</code> 以在核心 <code>0, 2, 4, ... OMP_NUM_THREADS
-
-
OMP_PROC_BIND指示 OpenMP 线程如何绑定到资源。我们可以提供一个由primary、close、spread或false组成的逗号分隔列表，以指示并行嵌套级别的策略。-
export OMP_PROC_BIND=close将线程绑定到给定位置的主要线程附近 -
export OMP_PROC_BIND=spread将线程均匀地分布在给定位置 -
export OMP_PROC_BIND=primary将线程绑定到与主线程相同的位置 -
export OMP_PROC_BIND=false禁用线程 Affinity
-
OpenMP 规范 包含有关这些环境变量和其他环境变量的更多详细信息。
如果使用 GNU OpenMP 实现来构建应用程序，我们还可以使用环境变量 GOMP_CPU_AFFINITY 为进程及其线程设置 Affinity。在下面的示例中，我们运行一个具有 16 个线程的进程，并将它们绑定到核心 0、4、8、... 60。
export GOMP_CPU_AFFINITY=0-63:4export OMP_NUM_THREADS=16./exe多进程 (MPI)，多线程应用程序
使用 MPI 支持构建的多进程应用程序有多种进程放置、顺序和绑定的选项，具体取决于构建应用程序的 MPI 实现或用于提交作业的调度程序。
OpenMPI 的 mpirun 命令提供了多个与 Affinity 相关的选项，例如 —map-by 和 —report-bindings。 mpirun man page 包含有关这些选项和其他详细信息的广泛文档。下面显示了运行 4 个 MPI rank 的示例，其中每个 rank 有 2 个 OpenMP 线程，使用 OpenMPI 5.0.2。在此，我们混合使用 mpirun 选项和 OpenMP 环境变量，将每个 rank 的两个线程分布在 NUMA 域中，并将每个 rank 保持在其自己的 NUMA 域中。
OMP_NUM_THREADS=2 OMP_PROC_BIND=spread mpirun -np 4 --map-by NUMA ./hello_mpi_omp上述示例还展示了运行hello_mpi_omp 以通过编程方式验证绑定。下面显示的样本输出是在拓扑与本文节点拓扑 – lstopo部分所示拓扑相似的节点上获得的。在此，我们看到每个 MPI rank 被固定到来自唯一 NUMA 域的两个 HWT。
MPI 000 - OMP 000 - HWT 000MPI 000 - OMP 001 - HWT 008MPI 002 - OMP 000 - HWT 032MPI 002 - OMP 001 - HWT 040MPI 003 - OMP 000 - HWT 048MPI 003 - OMP 001 - HWT 056MPI 001 - OMP 000 - HWT 016MPI 001 - OMP 001 - HWT 024请注意，mpirun 在某些情况下会自动将进程绑定到硬件资源，这有时会令人非常困惑。我们敦促您在绑定选项未达到预期结果时查阅 mpirun man 页，并查找任何默认设置，例如OpenMPI 5.0 手册中描述的设置。
Slurm 作业调度程序提供了丰富的选项来控制任务绑定到硬件资源。有关所有此类选项的文档，请参阅 srun 或 slurm.conf 的 man 页。需要注意的是，Slurm 配置在每个站点都不同，因此我们鼓励您检查您站点的系统管理员的建议。
MPICH 没有太多与 Affinity 相关的选项，但如果它与 Slurm 集成构建，则可以在运行时使用 slurm 绑定来设置 Affinity。
在 CPU + GPU 上运行的混合应用程序
在同时使用 CPU 核心和 GPU(s) 的混合应用程序中，我们还需要额外控制每个进程到 GPU 设备的 Affinity。默认情况下，所有进程都可以看到所有 GPU 设备。在本系列博客的第一部分中，我们了解了将进程映射到同一 NUMA 域中的 GPU 设备和 CPU 核心的重要性。现在，我们将探讨实现这一目标的各种方法。我们的目标是为您提供不同的技术，以便您可以确定在您的系统上最有效的方法。
使用 HIP 运行时或 ROCr 运行时（ROCm 堆栈中的较低级别运行时库）构建的应用程序或库（如 MPI）。根据使用的运行时库，可以使用以下两个环境变量之一来设置 GPU 设备的 Affinity。对于 HIP 应用程序，可以使用环境变量HIP_VISIBLE_DEVICES 来限制 HIP 运行时可见的 GPU 设备。在已使用 OpenMP 目标卸载功能将计算卸载到 GPU 的应用程序中，可以使用环境变量ROCR_VISIBLE_DEVICES 来限制 ROCR 运行时可见的 GPU 设备。由于 HIP 运行时依赖于 ROCr 运行时，请注意，只有 ROCR_VISIBLE_DEVICES 使可见的 GPU 设备子集可能会受到 HIP_VISIBLE_DEVICES 的进一步限制。
在某些 HPC 站点，存在便捷的 slurm 绑定，可以轻松实现此类 Affinity 控制。Frontier 用户指南提供了使用 Slurm 选项在 Frontier 上将进程及其线程映射到 CPU、GPU 和 NIC 的优秀文档。
在某些情况下，当使用 OpenMPI 和 OpenMP 选项实现 CPU 绑定时（如上一节所示），可以通过一个由 mpirun 在实际可执行文件之前运行的包装器脚本来完成 GPU Affinity 的设置。为了给您一个想法，下面显示了一个简单的包装器脚本，它使用本地 rank ID 将 8 个进程映射到节点上的 8 个 GPU 设备。
$ cat set_gpu_device.sh#!/bin/bashexport HIP_VISIBLE_DEVICES=$OMPI_COMM_WORLD_LOCAL_RANKexec $*现在，以前面章节中运行 8 个 MPI rank（每个 rank 运行 2 个 OpenMP 线程）在具有 8 个 GPU 的节点上的相同示例为例，我们可以使用以下命令映射 CPU 和 GPU：
OMP_NUM_THREADS=2 OMP_PROC_BIND=spread mpirun -np 4 --map-by NUMA ./set_gpu_device.sh ./hello_jobstep请注意，这次我们运行了 hello_jobstep 程序来验证 CPU 和 GPU 绑定。上述命令的输出显示每个 rank 使用不同的 GPU 设备。
MPI 000 - OMP 000 - HWT 000 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63MPI 000 - OMP 001 - HWT 008 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63MPI 001 - OMP 000 - HWT 016 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43MPI 001 - OMP 001 - HWT 024 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43MPI 002 - OMP 000 - HWT 032 - RT_GPU_ID 0 - GPU_ID 2 - Bus_ID 03MPI 002 - OMP 001 - HWT 040 - RT_GPU_ID 0 - GPU_ID 2 - Bus_ID 03MPI 003 - OMP 000 - HWT 048 - RT_GPU_ID 0 - GPU_ID 3 - Bus_ID 27MPI 003 - OMP 001 - HWT 056 - RT_GPU_ID 0 - GPU_ID 3 - Bus_ID 27在AMD lab notes 仓库中可以找到一个稍加扩展的脚本，该脚本为更通用的场景（例如在多个节点上运行、在每个 GPU 设备上打包多个 rank、步进 OpenMP 线程或步进 MPI rank 以在可用套接字上均匀分布进程）设置 CPU 和 GPU Affinity。由于此脚本同时管理 CPU 和 GPU Affinity 设置，因此重要的是使用 mpirun —bind-to none 选项，而不是使用 OMP_PROC_BIND 设置或 —map-by mpirun 选项。此脚本可以轻松扩展以与其他 MPI 环境（如 MPICH 或 Slurm）配合使用。下面是一个示例，显示了在节点上运行 16 个 MPI rank（每个 rank 8 个线程）和 8 个 GPU，因此每个 GPU 被 2 个 MPI rank 超额订阅。
OMP_NUM_THREADS=8 mpirun -np 16 --bind-to=none ./set_cpu_and_gpu_affinity.sh ./hello_jobstep在下面显示的部分输出中，我们观察到 MPI rank 0 和 1 运行在 GPU 0 上，MPI rank 2 和 3 运行在 GPU 1 上，依此类推。Rank 0 和 1 在 NUMA 域 0（核心 0-15）中紧密打包，每个线程有一个物理核心。对于此节点上的 NPS4 配置，要获得完整的 CPU 内存带宽，我们需要将进程和线程均匀地分布在两个插槽上。
MPI 000 - OMP 000 - HWT 000 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63MPI 000 - OMP 002 - HWT 002 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63MPI 000 - OMP 007 - HWT 007 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63MPI 000 - OMP 006 - HWT 006 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63MPI 000 - OMP 001 - HWT 001 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63MPI 000 - OMP 005 - HWT 005 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63MPI 000 - OMP 003 - HWT 003 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63MPI 000 - OMP 004 - HWT 004 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63MPI 001 - OMP 000 - HWT 008 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63MPI 001 - OMP 003 - HWT 011 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63MPI 001 - OMP 001 - HWT 009 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63MPI 001 - OMP 006 - HWT 014 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63MPI 001 - OMP 005 - HWT 013 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63MPI 001 - OMP 002 - HWT 010 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63MPI 001 - OMP 004 - HWT 012 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63MPI 001 - OMP 007 - HWT 015 - RT_GPU_ID 0 - GPU_ID 0 - Bus_ID 63MPI 002 - OMP 000 - HWT 016 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43MPI 002 - OMP 006 - HWT 022 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43MPI 002 - OMP 002 - HWT 018 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43MPI 002 - OMP 004 - HWT 020 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43MPI 002 - OMP 005 - HWT 021 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43MPI 002 - OMP 003 - HWT 019 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43MPI 002 - OMP 007 - HWT 023 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43MPI 002 - OMP 001 - HWT 017 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43MPI 003 - OMP 000 - HWT 024 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43MPI 003 - OMP 001 - HWT 025 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43MPI 003 - OMP 002 - HWT 026 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43MPI 003 - OMP 004 - HWT 028 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43MPI 003 - OMP 003 - HWT 027 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43MPI 003 - OMP 006 - HWT 030 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43MPI 003 - OMP 005 - HWT 029 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43MPI 003 - OMP 007 - HWT 031 - RT_GPU_ID 0 - GPU_ID 1 - Bus_ID 43结论
Affinity 是实现 HPC 应用程序更好性能的重要考虑因素。设置 Affinity 包括了解系统拓扑以及如何控制当前应用程序和系统的映射。在本博客中，我们为读者提供了几种用于研究系统和控制 Affinity 的工具和技术，并相应地进行放置和排序。本文绝非关于控制 Affinity 的所有可能方式的全面权威，而是展示了可能性的一个小型样本。我们强调阅读所有这些工具的 man 页的重要性，以确定哪些适合您的系统。如果您有任何问题或意见，我们鼓励您参与Github 讨论。
参考文献
-
并行和高性能计算，Robert Robey 和 Yuliana Zamora，Manning Publications，2021 年 5 月
-
CP2K 代码在 CPU 和 GPU 上的从头分子动力学性能分析，Dewi Yokelson，Nikolay V. Tkachenko，Robert Robey，Ying Wai Li 和 Pavel A. Dub，《Journal of Chemical Information and Modeling 2022 62 (10)》，2378-2386，DOI：10.1021/acs.jcim.1c01538
-
ORNL 代码示例
免责声明
OpenMP 名称和 OpenMP 徽标是 OpenMP 架构审查委员会的注册商标。
HPE 是 Hewlett Packard Enterprise Company 和/或其关联公司的注册商标。
Linux 是 Linus Torvalds 在美国和其他国家/地区的注册商标。
