问是否可以强迫cudaMallocManaged在特定的gpu id上分配(例如通过cudaSetDevice)

EN

不，你不能通过cudaMallocManaged直接做。托管内存背后的思想是，分配迁移到任何需要的处理器上。

如果您希望手动确保托管分配在特定GPU上“呈现”(迁移到)，则通常使用cudaMemPrefetchAsync。一些例子是这里和这里。如果您知道需要在哪个GPU上使用数据，而不是使用“按需”迁移，则通常推荐这样做以获得良好的性能。

一些关于托管内存/统一内存使用的博客是这里和这里，还有一些已记录的培训是可用的这里，第6节。

来自N.2.1.1.使用cudaMallocManaged()的显式分配 (重点雷)：

默认情况下，计算能力低于6.x的设备直接在GPU上分配托管内存。但是，当调用cudaMallocManaged()时，计算能力6.x或更高的设备不分配物理内存:在这种情况下，物理内存是在第一次触摸上填充的，并且可能驻留在CPU或GPU上。

因此，对于最近的任何体系结构，它的工作方式就像CPU上的NUMA节点:分配并没有说明内存的物理分配位置。相反，这取决于“第一次触摸”，即初始化。因此，只要第一次写入这些位置来自GPU，您希望它是常驻，您是好的。

因此，我也不认为一个特性请求会得到支持。在这个内存模型中，分配和放置只是完全独立的操作。

除了Robert描述的显式预取之外，您还可以使用cudaMemAdvise (参见N.3.2.数据使用提示)提供更多信息，说明哪些设备将以哪种方式访问哪个内存位置(读/写)。

所有这些背后的想法是，您可以从仅仅使用cudaMallocManaged开始，而不关心快速原型过程中的位置等等。稍后，您将分析代码，然后使用提示和预取来优化缓慢的部分，以获得(几乎)与显式内存管理和副本相同的性能。最后的代码可能不像显式管理那样容易阅读/不那么复杂(例如，cudaMemcpy被cudaMemPrefetchAsync取代)，但最大的区别是，对于某些性能较差的错误，您要为某些错误付出代价，而不是使用错误的应用程序，例如可能被忽略的损坏数据。

在多GPU应用程序中，这种在一开始就不关心位置的想法可能不适用，但NVIDIA似乎希望cudaMallocManaged对于这种类型的工作流尽可能简单。