Настройка Slurm для разделов CPU / GPU - PullRequest
0 голосов
/ 28 февраля 2020

У меня есть гибридный кластер с 2 графическими процессорами и 2 20-ядерными процессорами на каждом узле.

Я создал два раздела: - «cpu» для заданий только с процессором, которым разрешено выделять до 38 ядер. на узел - «gpu» для заданий только для графических процессоров, которым разрешено выделять до 2 графических процессоров и 2 процессорных ядер.

Соответствующие разделы в slurm.conf:

# NODES
NodeName=node[01-06] Sockets=2 CoresPerSocket=20 ThreadsPerCore=1 Gres=gpu:2(S:0-1) RealMemory=257433

# PARTITIONS
PartitionName=cpu Default=YES Nodes=node[01-06] MaxNodes=6 MinNodes=0 DefaultTime=04:00:00 MaxTime=14-00:00:00 MaxCPUsPerNode=38
PartitionName=gpu             Nodes=node[01-06] MaxNodes=6 MinNodes=0 DefaultTime=04:00:00 MaxTime=14-00:00:00 MaxCPUsPerNode=2

и в gres .conf:

Name=gpu Type=v100 File=/dev/nvidia0 Cores=0-19
Name=gpu Type=v100 File=/dev/nvidia1 Cores=20-39

Однако, похоже, он не работает должным образом. Если я сначала отправляю задание GPU, используя все доступные ресурсы раздела «gpu», а затем задание CPU, распределяя остальные ядра процессора (т.е. 38 ядер на узел) в разделе «cpu», это работает отлично. Обе работы начинают выполняться. Но если я изменил порядок отправки и запустил CPU-задание перед GPU-заданием, задание «cpu» запускается, пока задание «gpu» остается в очереди с состоянием PENDING и причиной RESOURCES.

Моим первым предположением было это задание "cpu" распределяет ядра, назначенные соответствующим графическим процессорам в gres.conf, и не позволяет устройствам GPU работать. Однако, похоже, что это не так, потому что 37 ядерных задач на узел вместо 38 решают проблему.

Другая мысль заключалась в том, что это как-то связано с резервированием специализированных ядер, но я попытался изменить опцию CoreSpecCount без успеха.

Итак, есть идеи, как исправить это поведение и где искать?

Спасибо!

...