一个 K80 内两个 GPU 的 CUDA 感知 MPI
CUDA-aware MPI for two GPUs within one K80
我正在尝试优化名为 LAMMPS (https://github.com/lammps/lammps) 的 MPI+CUDA 基准测试的性能。现在我 运行 两个 MPI 进程和两个 GPU。我的系统有两个插座，每个插座连接到 2 个 K80。由于每个 K80 内部包含 2 个 GPU，因此每个插槽实际上连接到 4 个 GPU。但我只在一个插槽中使用 2 个内核，并在该插槽上连接了 2 个 GPU（1 个 K80）。 MPI编译器是MVAPICH2 2.2rc1，CUDA编译器版本是7.5.
那是背景。我分析了应用程序，发现通信是性能瓶颈。我怀疑这是因为没有应用 GPUDirect 技术。所以我切换到 MVAPICH2-GDR 2.2rc1 并安装了所有其他必需的库和工具。但是 MVAPICH2-GDR 需要在我的系统上不可用的 Infiniband 接口卡，所以我有运行时错误 "channel initialization failed. No active HCAs found on the system"。根据我的理解，如果我们只想在一个节点上使用 1 个 K80 以内的 GPU，则不需要 Infiniband 卡，因为 K80 有一个用于这两个 GPU 的内部 PCIe 开关。这些是我的疑惑。为了把问题说清楚，我罗列如下：
在我的系统中，一个插座连接两个K80。如果一个K80的两个GPU需要和另一个K80的GPU通信，那么我们要使用GPUDirect就必须有IB卡，对吗？
如果我们只需要用到1个K80内的两个GPU，那么这两个GPU之间的通信就不需要IB卡了吧？但是，MVAPICH2-GDR 至少需要一张 IB 卡。那么有什么解决方法可以解决这个问题吗？或者我必须在系统上插入IB卡？
In my system, one socket connects to two K80. If two GPUs in one K80 need to communicate with the GPUs in another K80, then we must have IB card if we want to use GPUDirect, is that right?
唯一需要 IB 卡的时间是当您有从一个系统到另一个系统的 MPI 通信（GPU 或其他）时。同一系统中的 GPU 不需要 IB 卡就可以相互通信。下面是有关在此（单系统）设置中使用 GPUDirect 的更多信息。
If we only need to use the two GPUs within 1 K80, then the communication between these two GPUs does not require IB card, right? However, MVAPICH2-GDR requires at least one IB card. So is there any workaround to solve this issue? Or I have to plugin a IB card on the system?
MVAPICH2-GDR中的GDR是指GPUDirect-RDMA。 GPUDirect 是一组允许 GPU 直接相互通信的技术的总称。
对于同一系统中的GPU，GPUDirect技术被称为Peer-to-Peer。 K80 上的两个 GPU 应该始终能够使用点对点相互通信，您可以使用名称中包含 P2P 的 CUDA 示例代码（例如 simpleP2P）自行验证这一点。此示例代码还将告诉您您的系统是否能够支持同一系统中任意 2 个 GPU 之间的 P2P。
对于通过 IB (Infiniband) 网络连接的独立系统中的 GPU，还有一种称为 GPUDirect-RDMA 的附加 GPUDirect 技术。这允许 独立 系统中的两个 GPU 通过 IB link.
相互通信
因此，由于 MVAPICH2-GDR 包含与 IB 相关的 GPUDirect RDMA，它可能会默认寻找 IB 卡。
但是，即使在单个系统（例如 K80）中的 GPU 之间，您也应该能够通过使用支持 GPUDirect 的 MPI（包括某些 MVAPICH2 风格）获得通信优势。这种用法简称为"CUDA-aware MPI"，因为它用的是GPUDirect P2P，不一定是RDMA。
关于如何设置它的详细教程和演练超出了我在 SO 答案中提供的范围，但有关这种用法的更多信息，我建议您参阅两篇全面介绍该主题的博客文章, 第一个是 here, the second part is here. More information on GPUDirect-RDMA is here.
我正在尝试优化名为 LAMMPS (https://github.com/lammps/lammps) 的 MPI+CUDA 基准测试的性能。现在我 运行 两个 MPI 进程和两个 GPU。我的系统有两个插座，每个插座连接到 2 个 K80。由于每个 K80 内部包含 2 个 GPU，因此每个插槽实际上连接到 4 个 GPU。但我只在一个插槽中使用 2 个内核，并在该插槽上连接了 2 个 GPU（1 个 K80）。 MPI编译器是MVAPICH2 2.2rc1，CUDA编译器版本是7.5.
那是背景。我分析了应用程序，发现通信是性能瓶颈。我怀疑这是因为没有应用 GPUDirect 技术。所以我切换到 MVAPICH2-GDR 2.2rc1 并安装了所有其他必需的库和工具。但是 MVAPICH2-GDR 需要在我的系统上不可用的 Infiniband 接口卡，所以我有运行时错误 "channel initialization failed. No active HCAs found on the system"。根据我的理解，如果我们只想在一个节点上使用 1 个 K80 以内的 GPU，则不需要 Infiniband 卡，因为 K80 有一个用于这两个 GPU 的内部 PCIe 开关。这些是我的疑惑。为了把问题说清楚，我罗列如下：
在我的系统中，一个插座连接两个K80。如果一个K80的两个GPU需要和另一个K80的GPU通信，那么我们要使用GPUDirect就必须有IB卡，对吗？
如果我们只需要用到1个K80内的两个GPU，那么这两个GPU之间的通信就不需要IB卡了吧？但是，MVAPICH2-GDR 至少需要一张 IB 卡。那么有什么解决方法可以解决这个问题吗？或者我必须在系统上插入IB卡？
In my system, one socket connects to two K80. If two GPUs in one K80 need to communicate with the GPUs in another K80, then we must have IB card if we want to use GPUDirect, is that right?
唯一需要 IB 卡的时间是当您有从一个系统到另一个系统的 MPI 通信（GPU 或其他）时。同一系统中的 GPU 不需要 IB 卡就可以相互通信。下面是有关在此（单系统）设置中使用 GPUDirect 的更多信息。
If we only need to use the two GPUs within 1 K80, then the communication between these two GPUs does not require IB card, right? However, MVAPICH2-GDR requires at least one IB card. So is there any workaround to solve this issue? Or I have to plugin a IB card on the system?
MVAPICH2-GDR中的GDR是指GPUDirect-RDMA。 GPUDirect 是一组允许 GPU 直接相互通信的技术的总称。
对于同一系统中的GPU，GPUDirect技术被称为Peer-to-Peer。 K80 上的两个 GPU 应该始终能够使用点对点相互通信，您可以使用名称中包含 P2P 的 CUDA 示例代码（例如 simpleP2P）自行验证这一点。此示例代码还将告诉您您的系统是否能够支持同一系统中任意 2 个 GPU 之间的 P2P。
对于通过 IB (Infiniband) 网络连接的独立系统中的 GPU，还有一种称为 GPUDirect-RDMA 的附加 GPUDirect 技术。这允许 独立 系统中的两个 GPU 通过 IB link.
相互通信因此，由于 MVAPICH2-GDR 包含与 IB 相关的 GPUDirect RDMA，它可能会默认寻找 IB 卡。
但是，即使在单个系统（例如 K80）中的 GPU 之间，您也应该能够通过使用支持 GPUDirect 的 MPI（包括某些 MVAPICH2 风格）获得通信优势。这种用法简称为"CUDA-aware MPI"，因为它用的是GPUDirect P2P，不一定是RDMA。
关于如何设置它的详细教程和演练超出了我在 SO 答案中提供的范围，但有关这种用法的更多信息，我建议您参阅两篇全面介绍该主题的博客文章, 第一个是 here, the second part is here. More information on GPUDirect-RDMA is here.