调度程序不遵守 OpenCL 子设备关联

Posted 2023-02-16

【中文标题】调度程序不遵守 OpenCL 子设备关联

【英文标题】：OpenCL subdevice affinity not respected by scheduler

【发布时间】：2015-01-03 12:23:51

【问题描述】：

我正在尝试编写一个 OpenCL 概念验证应用程序，该应用程序在特定 CPU 上执行内核（因此将来可以扩展为支持 NUMA 并为相应 NUMA 上的内核执行分配内存-节点，正如in the Intel Dev forums 指出的那样。

不幸的是，Windows 调度程序并不关心我想要什么，因为它似乎将我的内核循环通过所有可用的 CPU 内核（因此远离本地内存）。

我现在正在使用CL_DEVICE_PARTITION_BY_COUNTS 属性创建一个只有一个执行单元的子设备，然后我在这个子设备上执行内核。尽管如此，当我查看 Windows 的 CPU 使用率时，并不是单个内核很忙，而是多个内核的工作负载出现峰值（除非我使用任务管理器手动将进程固定到一个内核 - 然后我得到结果我一直期待）。

这是我用来创建子设备的属性的完整定义（如果我查询子设备的执行单元数，它会正确地给我“1”）：

cl_device_partition_property props[4];
props[0] = CL_DEVICE_PARTITION_BY_COUNTS;
props[1] = 1;
props[2] = CL_DEVICE_PARTITION_BY_COUNTS_LIST_END;
props[3] = 0;

我正在使用带有两个 Intel Xeon 处理器的 Windows 机器（顺便说一下，Intel OpenCL 实现将它们识别为一个具有 24 个执行单元的执行设备）并且还尝试使用 CL_DEVICE_PARTITION_BY_NAMES_INTEL，但它没有也可以解决）。

我做错了什么（或理解错误的方式）？

感谢您的帮助。

【参考方案1】：

您是否尝试过使用这些标志中的任何一个？

CL_AFFINITY_DOMAIN_L1_CACHE_EXT                 0x1
CL_AFFINITY_DOMAIN_L2_CACHE_EXT                 0x2
CL_AFFINITY_DOMAIN_L3_CACHE_EXT                 0x3
CL_AFFINITY_DOMAIN_L4_CACHE_EXT                 0x4
CL_AFFINITY_DOMAIN_NUMA_EXT                     0x10
CL_AFFINITY_DOMAIN_NEXT_FISSIONABLE_EXT         0x100

我认为当您使用 CL_DEVICE_PARTITION_BY_COUNTS 时，您要求任何单个内核来完成这项工作。上面的标志将尝试根据缓存级别进行分组，无论如何这都是您的目标。我自己还没有测试过这个操作系统是否会尊重这种亲和力，但我希望它应该这样做。 read more here.

【讨论】：

是的，我尝试使用这些。不幸的是，英特尔 OpenCL SDK 和 AMD OpenCL SDK（/驱动程序）目前似乎都不支持关联域。