Generic Resource (GRES) Scheduling

Contents

Overview
Configuration
Running Jobs
GPU Management
MPS Management
MIC Management

Overview

Generic resource (GRES) scheduling is supported through a flexible plugin mechanism. Support is currently provided for Graphics Processing Units (GPUs), CUDA Multi-Process Service (MPS), and Intel® Many Integrated Core (MIC) processors.
汎用リソース（GRES）スケジューリングは、柔軟なプラグインメカニズムを通じてサポートされます。現在、グラフィックスプロセッシングユニット（GPU）、CUDAマルチプロセスサービス（MPS）、およびIntel®Many Integrated Core（MIC）プロセッサーがサポートされています。

Configuration

Slurm supports no generic resources in the default configuration. One must explicitly specify which resources are to be managed in the slurm.conf configuration file. The configuration parameters of interest are GresTypes and Gres.
Slurmは、デフォルト構成では汎用リソースをサポートしていません。管理するリソースをslurm.conf構成ファイルで明示的に指定する必要があります。対象となる構成パラメーターは、GresTypesとGresです。

For more details, see GresTypes and Gres in the slurm.conf man page.
詳細については、slurm.conf manページのGresTypesとGresを参照してください。

Note that the GRES specification for each node works in the same fashion as the other resources managed. Nodes which are found to have fewer resources than configured will be placed in a DRAIN state.
各ノードのGRES仕様は、管理されている他のリソースと同じように機能することに注意してください。構成されているよりもリソースが少ないことが判明したノードは、DRAIN状態になります。

Snippet from an example slurm.conf file:
slurm.confファイルの例からの抜粋：

# Configure support for our four GPUs (with MPS), plus bandwidth
GresTypes=gpu,mps,bandwidth
NodeName=tux[0-7] Gres=gpu:tesla:2,gpu:kepler:2,mps:400,bandwidth:lustre:no_consume:4G

Each compute node with generic resources typically contain a gres.conf file describing which resources are available on the node, their count, associated device files and cores which should be used with those resources.
一般的なリソースを持つ各計算ノードには、通常、ノードで使用可能なリソース、それらの数、関連するデバイスファイル、およびこれらのリソースで使用する必要があるコアを説明するgres.confファイルが含まれています。

If AutoDetect=nvml is set in gres.conf, and the NVIDIA Management Library (NVML) is installed on the node and was found during Slurm configuration, configuration details will automatically be filled in for any system-detected NVIDIA GPU. This removes the need to explicitly configure GPUs in gres.conf, though the Gres= line in slurm.conf is still required in order to tell slurmctld how many GRES to expect.
AutoDetect = nvmlがgres.confで設定され、NVIDIA管理ライブラリ（NVML）がノードにインストールされ、Slurmの構成中に検出された場合、構成の詳細は、システムで検出されたNVIDIA GPUに対して自動的に入力されます。これにより、slurmctldに必要なGRESの数を通知するためにslurm.confのGres =行が依然として必要ですが、gres.confでGPUを明示的に構成する必要がなくなります。

By default, all system-detected devices are added to the node. However, if Type and File in gres.conf match a GPU on the system, any other properties explicitly specified (e.g. Cores or Links) can be double-checked against it. If the system-detected GPU differs from its matching GPU configuration, then the GPU is omitted from the node with an error. This allows gres.conf to serve as an optional sanity check and notifies administrators of any unexpected changes in GPU properties.
デフォルトでは、システムで検出されたすべてのデバイスがノードに追加されます。ただし、gres.confのTypeとFileがシステムのGPUと一致する場合、明示的に指定されたその他のプロパティ（コアやリンクなど）は、それに対してダブルチェックできます。システムが検出したGPUが対応するGPU構成と異なる場合、GPUはエラーでノードから除外されます。これにより、gres.confをオプションのサニティチェックとして機能させ、GPUプロパティの予期しない変更を管理者に通知できます。

To view available gres.conf configuration parameters, see the gres.conf man page.
使用可能なgres.conf構成パラメーターを表示するには、gres.confのmanページを参照してください。

Example gres.conf file:

# Configure support for four GPUs (with MPS), plus bandwidth
AutoDetect=nvml
Name=gpu Type=gp100  File=/dev/nvidia0 Cores=0,1
Name=gpu Type=gp100  File=/dev/nvidia1 Cores=0,1
Name=gpu Type=p6000  File=/dev/nvidia2 Cores=2,3
Name=gpu Type=p6000  File=/dev/nvidia3 Cores=2,3
Name=mps Count=200  File=/dev/nvidia0
Name=mps Count=200  File=/dev/nvidia1
Name=mps Count=100  File=/dev/nvidia2
Name=mps Count=100  File=/dev/nvidia3
Name=bandwidth Type=lustre Count=4G Flags=CountOnly

In this example, since AutoDetect=nvml is specified, Cores for each GPU will be checked against a corresponding GPU found on the system matching the Type and File specified. Since Links is not specified, it will be automatically filled in according to what is found on the system. If a matching system GPU is not found, no validation takes place and the GPU is assumed to be as the configuration says.
この例では、AutoDetect = nvmlが指定されているため、各GPUのコアは、指定されたタイプとファイルに一致するシステム上にある対応するGPUに対してチェックされます。リンクは指定されていないため、システムで検出された内容に従って自動的に入力されます。一致するシステムGPUが見つからない場合、検証は行われず、GPUは構成が示すとおりであると見なされます。

Running Jobs

Jobs will not be allocated any generic resources unless specifically requested at job submit time using the options:
次のオプションを使用してジョブの送信時に特に要求されない限り、ジョブには汎用リソースが割り当てられません。

--gres

Generic resources required per node
ノードごとに必要な汎用リソース

--gpus

GPUs required per job
ジョブごとに必要なGPU

--gpus-per-node

GPUs required per node. Equivalent to the --gres option for GPUs.
ノードごとに必要なGPU。GPUの--gresオプションと同等です。

--gpus-per-socket

GPUs required per socket. Requires the job to specify a task socket.
ソケットごとにGPUが必要です。タスクソケットを指定するジョブが必要です。

--gpus-per-task

GPUs required per task. Requires the job to specify a task count.
タスクごとに必要なGPU。ジョブにタスク数を指定する必要があります。

All of these options are supported by the salloc, sbatch and srun commands. Note that all of the --gpu* options are only supported by Slurm's select/cons_tres plugin. Jobs requesting these options when the select/cons_tres plugin is not configured will be rejected. The --gres option requires an argument specifying which generic resources are required and how many resources using the form name[:type:count] while all of the --gpu* options require an argument of the form [type]:count.
これらのオプションはすべて、salloc、sbatch、およびsrunコマンドでサポートされています。すべての--gpu *オプションは、Slurmのselect / cons_tresプラグインでのみサポートされていることに注意してください。select / cons_tresプラグインが構成されていないときにこれらのオプションを要求するジョブは拒否されます。--gresオプションには、必要な汎用リソースと、name [：type：count]形式を使用するリソースの数を指定する引数が必要ですが、すべての--gpu *オプションには、[type]：count形式の引数が必要です。
The name is the same name as specified by the GresTypes and Gres configuration parameters. type identifies a specific type of that generic resource (e.g. a specific model of GPU). count specifies how many resources are required and has a default value of 1. For example:
sbatch --gres=gpu:kepler:2 ....
この名前は、GresTypesおよびGres構成パラメーターで指定された名前と同じです。typeは、その汎用リソースの特定のタイプ（GPUの特定のモデルなど）を識別します。countは必要なリソースの数を指定し、デフォルト値は1です。例：sbatch --gres = gpu：kepler：2 ...

Several addition resource requirement specifications are available specifically for GPUs and detailed descriptions about these options are available in the man pages for the job submission commands. As for the --gpu* option, these options are only supported by Slurm's select/cons_tres plugin.
いくつかの追加のリソース要件の仕様は、特にGPUで利用可能であり、これらのオプションの詳細な説明は、ジョブ送信コマンドのmanページで利用可能です。--gpu *オプションについては、これらのオプションはSlurmのselect / cons_tresプラグインでのみサポートされています。

--cpus-per-gpu

Count of CPUs allocated per GPU.
GPUごとに割り当てられたCPUの数。

--gpu-bind

Define how tasks are bound to GPUs.
タスクがGPUにバインドされる方法を定義します。

--gpu-freq

Specify GPU frequency and/or GPU memory frequency.
GPU周波数またはGPUメモリ周波数、あるいはその両方を指定します。

--mem-per-gpu

Memory allocated per GPU.
GPUごとに割り当てられるメモリ。

Jobs will be allocated specific generic resources as needed to satisfy the request. If the job is suspended, those resources do not become available for use by other jobs.
ジョブには、要求を満たすために必要に応じて特定の総称リソースが割り当てられます。ジョブが中断されると、それらのリソースは他のジョブで使用できなくなります。

Job steps can be allocated generic resources from those allocated to the job using the --gres option with the srun command as described above. By default, a job step will be allocated all of the generic resources allocated to the job. If desired, the job step may explicitly specify a different generic resource count than the job.
上記のように、srunコマンドで--gresオプションを使用すると、ジョブステップにジョブに割り当てられたリソースから汎用リソースを割り当てることができます。デフォルトでは、ジョブステップには、ジョブに割り当てられているすべての汎用リソースが割り当てられます。必要に応じて、ジョブステップはジョブとは異なる汎用リソースカウントを明示的に指定できます。
This design choice was based upon a scenario where each job executes many job steps. If job steps were granted access to all generic resources by default, some job steps would need to explicitly specify zero generic resource counts, which we considered more confusing. The job step can be allocated specific generic resources and those resources will not be available to other job steps. A simple example is shown below.
この設計の選択は、各ジョブが多くのジョブステップを実行するシナリオに基づいていました。ジョブステップにデフォルトですべての汎用リソースへのアクセスが許可されている場合、一部のジョブステップでは、ジェネリックリソースカウントを明示的に0に指定する必要があります。ジョブステップには特定の汎用リソースを割り当てることができ、それらのリソースは他のジョブステップでは使用できません。簡単な例を以下に示します。

#!/bin/bash
#
# gres_test.bash
# Submit as follows:
# sbatch --gres=gpu:4 -n4 -N1-1 gres_test.bash
#
srun --gres=gpu:2 -n2 --exclusive show_device.sh &
srun --gres=gpu:1 -n1 --exclusive show_device.sh &
srun --gres=gpu:1 -n1 --exclusive show_device.sh &
wait

GPU Management

In the case of Slurm's GRES plugin for GPUs, the environment variable CUDA_VISIBLE_DEVICES is set for each job step to determine which GPUs are available for its use on each node. This environment variable is only set when tasks are launched on a specific compute node (no global environment variable is set for the salloc command and the environment variable set for the sbatch command only reflects the GPUs allocated to that job on that node, node zero of the allocation).
SlurmのGPU用GRESプラグインの場合、環境変数CUDA_VISIBLE_DEVICESが各ジョブステップに設定され、各ノードで使用できるGPUを決定します。この環境変数は、特定の計算ノードでタスクが起動された場合にのみ設定されます（sallocコマンドにグローバル環境変数が設定されておらず、sbatchコマンドに設定された環境変数は、そのノードのノード0のそのジョブに割り当てられたGPUのみを反映しています割り当て）。
CUDA version 3.1 (or higher) uses this environment variable in order to run multiple jobs or job steps on a node with GPUs and ensure that the resources assigned to each are unique. In the example above, the allocated node may have four or more graphics devices. In that case, CUDA_VISIBLE_DEVICES will reference unique devices for each file and the output might resemble this:
CUDAバージョン3.1（またはそれ以上）は、GPUを備えたノードで複数のジョブまたはジョブステップを実行し、それぞれに割り当てられたリソースが一意であることを確認するために、この環境変数を使用します。上記の例では、割り当てられたノードに4つ以上のグラフィックデバイスが含まれている場合があります。その場合、CUDA_VISIBLE_DEVICESは各ファイルの一意のデバイスを参照し、出力は次のようになります。

JobStep=1234.0 CUDA_VISIBLE_DEVICES=0,1
JobStep=1234.1 CUDA_VISIBLE_DEVICES=2
JobStep=1234.2 CUDA_VISIBLE_DEVICES=3

NOTE: Be sure to specify the File parameters in the gres.conf file and ensure they are in the increasing numeric order.
注：必ずgres.confファイルでファイルパラメータを指定し、昇順の番号順になっていることを確認してください。

The CUDA_VISIBLE_DEVICES environment variable will also be set in the job's Prolog and Epilog programs. Note that the environment variable set for the job may differ from that set for the Prolog and Epilog if Slurm is configured to constrain the device files visible to a job using Linux cgroup. This is because the Prolog and Epilog programs run outside of any Linux cgroup while the job runs inside of the cgroup and may thus have a different set of visible devices.
CUDA_VISIBLE_DEVICES環境変数は、ジョブのPrologおよびEpilogプログラムでも設定されます。Linuxのcgroupを使用してジョブに表示されるデバイスファイルを制約するようにSlurmが構成されている場合、ジョブに設定された環境変数は、PrologおよびEpilogに設定されたものと異なる場合があります。これは、ジョブがcgroupの内部で実行されている間、PrologおよびEpilogプログラムがLinux cgroupの外部で実行されるため、表示されるデバイスのセットが異なる可能性があるためです。
For example, if a job is allocated the device "/dev/nvidia1", then CUDA_VISIBLE_DEVICES will be set to a value of "1" in the Prolog and Epilog while the job's value of CUDA_VISIBLE_DEVICES will be set to a value of "0" (i.e. the first GPU device visible to the job). For more information see the Prolog and Epilog Guide.
たとえば、ジョブにデバイス「/ dev / nvidia1」が割り当てられている場合、ジョブのCUDA_VISIBLE_DEVICESの値は「0」の値に設定されますが、プロローグとエピローグではCUDA_VISIBLE_DEVICESの値が「1」に設定されます。 （つまり、ジョブから見える最初のGPUデバイス）。詳細については、PrologおよびEpilogガイドを参照してください。

When possible, Slurm automatically determines the GPUs on the system using NVML. NVML (which powers the nvidia-smi tool) numbers GPUs in order by their PCI bus IDs. For this numbering to match the numbering reported by CUDA, the CUDA_DEVICE_ORDER environmental variable must be set to CUDA_DEVICE_ORDER=PCI_BUS_ID.
可能な場合、SlurmはNVMLを使用してシステム上のGPUを自動的に決定します。NVML（nvidia-smiツールの機能）は、PCIバスID順にGPUに番号を付けます。この番号付けがCUDAによって報告された番号付けと一致するには、CUDA_DEVICE_ORDER環境変数をCUDA_DEVICE_ORDER = PCI_BUS_IDに設定する必要があります。

GPU device files (e.g. /dev/nvidia1) are based on the Linux minor number assignment, while NVML's device numbers are assigned via PCI bus ID, from lowest to highest. Mapping between these two is indeterministic and system dependent, and could vary between boots after hardware or OS changes. For the most part, this assignment seems fairly stable. However, an after-bootup check is required to guarantee that a GPU device is assigned to a specific device file.
GPUデバイスファイル（たとえば、/ dev / nvidia1）はLinuxのマイナー番号割り当てに基づいていますが、NVMLのデバイス番号は、PCIバスIDを介して最小から最大まで割り当てられます。これら2つの間のマッピングは不確定でシステムに依存し、ハードウェアまたはOSの変更後のブート間で異なる可能性があります。ほとんどの場合、この割り当てはかなり安定しているようです。ただし、GPUデバイスが特定のデバイスファイルに割り当てられていることを保証するには、起動後のチェックが必要です。

Please consult the NVIDIA CUDA documentation for more information about the CUDA_VISIBLE_DEVICES and CUDA_DEVICE_ORDER environmental variables.
CUDA_VISIBLE_DEVICESおよびCUDA_DEVICE_ORDER環境変数の詳細については、NVIDIA CUDAのドキュメントを参照してください。

MPS Management

CUDA Multi-Process Service (MPS) provides a mechanism where GPUs can be shared by multiple jobs, where each job is allocated some percentage of the GPU's resources. The total count of MPS resources available on a node should be configured in the slurm.conf file (e.g. "NodeName=tux[1-16] Gres=gpu:2,mps:200"). Several options are available for configuring MPS in the gres.conf file as listed below with examples following that:
CUDAマルチプロセスサービス（MPS）は、GPUを複数のジョブで共有できるメカニズムを提供します。各ジョブには、GPUのリソースの一定の割合が割り当てられます。ノードで使用可能なMPSリソースの総数は、slurm.confファイルで構成する必要があります（例： "NodeName = tux [1-16] Gres = gpu：2、mps：200"）。以下にリストするように、gres.confファイルでMPSを構成するためのいくつかのオプションが使用できます。

1. No MPS configuration: The count of gres/mps elements defined in the slurm.conf will be evenly distributed across all GPUs configured on the node. For the example, "NodeName=tux[1-16] Gres=gpu:2,mps:200" will configure a count of 100 gres/mps resources on each of the two GPUs.
   MPS構成なし：slurm.confで定義されたgres / mps要素の数は、ノードに構成されたすべてのGPUに均等に分散されます。たとえば、「NodeName = tux [1-16] Gres = gpu：2、mps：200」は、2つのGPUのそれぞれに100 gres / mpsリソースのカウントを構成します。
   
2. MPS configuration includes only the Name and Count parameters: The count of gres/mps elements will be evenly distributed across all GPUs configured on the node. This is similar to case 1, but places duplicate configuration in the gres.conf file.
   MPS構成にはNameパラメーターとCountパラメーターのみが含まれます。gres/ mps要素の数は、ノードに構成されているすべてのGPUに均等に分散されます。これはケース1と似ていますが、重複した構成をgres.confファイルに配置します。
   
3. MPS configuration includes the Name, File and Count parameters: Each File parameter should identify the device file path of a GPU and the Count should identify the number of gres/mps resources available for that specific GPU device. This may be useful in a heterogeneous environment. For example, some GPUs on a node may be more powerful than others and thus be associated with a higher gres/mps count. Another use case would be to prevent some GPUs from being used for MPS (i.e. they would have an MPS count of zero).
   MPS構成には、Name、File、およびCountパラメーターが含まれます。各FileパラメーターはGPUのデバイスファイルパスを識別し、Countはその特定のGPUデバイスで使用可能なgres / mpsリソースの数を識別する必要があります。これは、異機種環境で役立つ場合があります。たとえば、ノード上の一部のGPUは他のGPUよりも強力であり、したがってより高いgres / mpsカウントに関連付けられている場合があります。もう1つの使用例は、一部のGPUがMPSに使用されないようにすることです（つまり、MPSカウントがゼロになります）。
   

Note that Type and Cores parameters for gres/mps are ignored. That information is copied from the gres/gpu configuration.
gres / mpsのTypeパラメータとCoresパラメータは無視されることに注意してください。その情報は、gres / gpu構成からコピーされます。

Note the Count parameter is translated to a percentage, so the value would typically be a multiple of 100.
Countパラメータはパーセントに変換されるため、値は通常100の倍数になることに注意してください。

Note that if NVIDIA's NVML library is installed, the GPU configuration (i.e. Type, File, Cores and Links data) will be automatically gathered from the library and need not be recorded in the gres.conf file.
NVIDIAのNVMLライブラリがインストールされている場合、GPU構成（タイプ、ファイル、コア、リンクのデータ）はライブラリから自動的に収集されるため、gres.confファイルに記録する必要はありません。

Note the same GPU can be allocated either as a GPU type of GRES or as an MPS type of GRES, but not both. In other words, once a GPU has been allocated as a gres/gpu resource it will not be available as a gres/mps. Likewise, once a GPU has been allocated as a gres/mps resource it will not be available as a gres/gpu. However the same GPU can be allocated as MPS generic resources to multiple jobs belonging to multiple users, so long as the total count of MPS allocated to jobs does not exceed the configured count. Some example configurations for Slurm's gres.conf file are shown below.
同じGPUをGRESタイプのGRESまたはMPSタイプのGRESとして割り当てることができますが、両方を割り当てることはできません。つまり、GPUがgres / gpuリソースとして割り当てられると、gres / mpsとして使用できなくなります。同様に、GPUがgres / mpsリソースとして割り当てられると、gres / gpuとして使用できなくなります。ただし、ジョブに割り当てられたMPSの合計数が構成された数を超えない限り、同じGPUをMPS汎用リソースとして複数のユーザーに属する複数のジョブに割り当てることができます。Slurmのgres.confファイルの構成例を以下に示します。

# Example 1 of gres.conf
# Configure support for four GPUs (with MPS)
AutoDetect=nvml
Name=gpu Type=gp100 File=/dev/nvidia0 Cores=0,1
Name=gpu Type=gp100 File=/dev/nvidia1 Cores=0,1
Name=gpu Type=p6000 File=/dev/nvidia2 Cores=2,3
Name=gpu Type=p6000 File=/dev/nvidia3 Cores=2,3
# Set gres/mps Count value to 100 on each of the 4 available GPUs
Name=mps Count=400

# Example 2 of gres.conf
# Configure support for four differernt GPU types (with MPS)
AutoDetect=nvml
Name=gpu Type=gtx1080 File=/dev/nvidia0 Cores=0,1
Name=gpu Type=gtx1070 File=/dev/nvidia1 Cores=0,1
Name=gpu Type=gtx1060 File=/dev/nvidia2 Cores=2,3
Name=gpu Type=gtx1050 File=/dev/nvidia3 Cores=2,3
Name=mps Count=1300   File=/dev/nvidia0
Name=mps Count=1200   File=/dev/nvidia1
Name=mps Count=1100   File=/dev/nvidia2
Name=mps Count=1000   File=/dev/nvidia3

NOTE: Slurm support for gres/mps requires the use of the select/cons_tres plugin.
注：gres / mpsのSlurmサポートには、select / cons_tresプラグインの使用が必要です。

Job requests for MPS will be processed the same as any other GRES except that the request must be satisfied using only one GPU per node and only one GPU per node may be configured for use with MPS. For example, a job request for "--gres=mps:50" will not be satisfied by using 20 percent of one GPU and 30 percent of a second GPU on a single node. Multiple jobs from different users can use MPS on a node at the same time. Note that GRES types of GPU and MPS can not be requested within a single job. Also jobs requesting MPS resources can not specify a GPU frequency.
MPSのジョブリクエストは他のGRESと同じように処理されますが、ノードごとに1つのGPUのみを使用してリクエストを満たす必要があり、ノードごとに1つのGPUのみをMPSで使用するように構成できます。たとえば、「-gres = mps：50」のジョブリクエストは、単一ノードで1つのGPUの20％と2つ目のGPUの30％を使用しても満たされません。異なるユーザーからの複数のジョブは、ノード上のMPSを同時に使用できます。GPUタイプのGPUおよびMPSは、単一のジョブ内では要求できないことに注意してください。また、MPSリソースを要求するジョブは、GPU周波数を指定できません。

A prolog program should be used to start and stop MPS servers as needed. A sample prolog script to do this is included with the Slurm distribution in the location etc/prolog.example. Its mode of operation is if a job is allocated gres/mps resources then the Prolog will have the CUDA_VISIBLE_DEVICES, CUDA_MPS_ACTIVE_THREAD_PERCENTAGE, and SLURM_JOB_UID environment variables set. The Prolog should then make sure that an MPS server is started for that GPU and user (UID == User ID). It also records the GPU device ID in a local file. If a job is allocated gres/gpu resources then the Prolog will have the CUDA_VISIBLE_DEVICES and SLURM_JOB_UID environment variables set (no CUDA_MPS_ACTIVE_THREAD_PERCENTAGE). The Prolog should then terminate any MPS server associated with that GPU. It may be necessary to modify this script as needed for the local environment. For more information see the Prolog and Epilog Guide.
必要に応じてMPSサーバーを起動および停止するには、プロローグプログラムを使用する必要があります。これを行うサンプルプロローグスクリプトは、Slurmディストリビューションのetc / prolog.exampleに含まれています。その動作モードは、ジョブにgres / mpsリソースが割り当てられている場合、PrologにはCUDA_VISIBLE_DEVICES、CUDA_MPS_ACTIVE_THREAD_PERCENTAGE、およびSLURM_JOB_UID環境変数が設定されます。次に、Prologは、そのGPUとユーザー（UID ==ユーザーID）に対してMPSサーバーが開始されていることを確認する必要があります。また、GPUデバイスIDをローカルファイルに記録します。ジョブにgres / gpuリソースが割り当てられている場合、PrologにはCUDA_VISIBLE_DEVICESおよびSLURM_JOB_UID環境変数が設定されます（CUDA_MPS_ACTIVE_THREAD_PERCENTAGEはありません）。その後、PrologはそのGPUに関連付けられているMPSサーバーを終了する必要があります。ローカル環境の必要に応じて、このスクリプトを変更する必要がある場合があります。詳細については、PrologおよびEpilogガイドを参照してください。

Jobs requesting MPS resources will have the CUDA_VISIBLE_DEVICES and CUDA_DEVICE_ORDER environment variables set. The device ID is relative to those resources under MPS server control and will always have a value of zero in the current implementation (only one GPU will be usable in MPS mode per node). The job will also have the CUDA_MPS_ACTIVE_THREAD_PERCENTAGE environment variable set to that job's percentage of MPS resources available on the assigned GPU. The percentage will be calculated based upon the portion of the configured Count on the Gres is allocated to a job of step. For example, a job requesting "--gres=gpu:200" and using configuration example 2 above would be allocated
MPSリソースを要求するジョブには、CUDA_VISIBLE_DEVICESおよびCUDA_DEVICE_ORDER環境変数が設定されます。デバイスIDは、MPSサーバーの制御下にあるこれらのリソースに関連しており、現在の実装では常に値がゼロになります（ノードごとにMPSモードで使用できるGPUは1つだけです）。また、ジョブには、CUDA_MPS_ACTIVE_THREAD_PERCENTAGE環境変数が、割り当てられたGPUで使用可能なMPSリソースのそのジョブのパーセンテージに設定されます。パーセンテージは、Gresで構成されたCountの部分に基づいて計算され、ステップのジョブに割り当てられます。たとえば、「-gres = gpu：200」を要求し、上記の構成例2を使用するジョブが割り当てられます

15% of the gtx1080 (File=/dev/nvidia0, 200 x 100 / 1300 = 15), or
16% of the gtx1070 (File=/dev/nvidia0, 200 x 100 / 1200 = 16), or
18% of the gtx1060 (File=/dev/nvidia0, 200 x 100 / 1100 = 18), or
20% of the gtx1050 (File=/dev/nvidia0, 200 x 100 / 1000 = 20).

An alternate mode of operation would be to permit jobs to be allocated whole GPUs then trigger the starting of an MPS server based upon comments in the job. For example, if a job is allocated whole GPUs then search for a comment of "mps-per-gpu" or "mps-per-node" in the job (using the "scontrol show job" command) and use that as a basis for starting one MPS daemon per GPU or across all GPUs respectively.
別の操作モードでは、ジョブにGPU全体を割り当てることを許可し、ジョブ内のコメントに基づいてMPSサーバーの起動をトリガーします。たとえば、ジョブにGPU全体が割り当てられている場合は、ジョブ内の「mps-per-gpu」または「mps-per-node」のコメントを検索し（「scontrol show job」コマンドを使用）、それを基準として使用しますGPUごとに、またはすべてのGPU全体でそれぞれ1つのMPSデーモンを開始します。

s

Please consult the NVIDIA Multi-Process Service documentation for more information about MPS.
MPSの詳細については、NVIDIAマルチプロセスサービスのドキュメントを参照してください。

Note that a vulnerability exists in previous versions of the NVIDIA driver that may affect users when sharing GPUs. More information can be found in CVE-2018-6260 and in the Security Bulletin: NVIDIA GPU Display Driver - February 2019.
以前のバージョンのNVIDIAドライバーには、GPUを共有するときにユーザーに影響を与える可能性のある脆弱性があることに注意してください。詳細については、CVE-2018-6260およびセキュリティ情報：NVIDIA GPUディスプレイドライバー-2019年2月をご覧ください。

MIC Management

Slurm can be used to provide resource management for systems with the Intel® Many Integrated Core (MIC) processor. Slurm sets an OFFLOAD_DEVICES environment variable, which controls the selection of MICs available to a job step. The OFFLOAD_DEVICES environment variable is used by both Intel LEO (Language Extensions for Offload) and the MKL (Math Kernel Library) automatic offload.
Slurmは、インテル®メニーインテグレーテッドコア（MIC）プロセッサーを搭載したシステムのリソース管理に使用できます。Slurmは、ジョブステップで使用可能なMICの選択を制御するOFFLOAD_DEVICES環境変数を設定します。OFFLOAD_DEVICES環境変数は、Intel LEO（オフロード用の言語拡張）とMKL（Math Kernel Library）自動オフロードの両方で使用されます。
(This is very similar to how the CUDA_VISIBLE_DEVICES environment variable is used to control which GPUs can be used by CUDA™ software.) If no MICs are reserved via GRES, the OFFLOAD_DEVICES variable is set to -1. This causes the code to ignore the offload directives and run MKL routines on the CPU. The code will still run but only on the CPU. This also gives a somewhat cryptic warning:
（これは、CUDA_VISIBLE_DEVICES環境変数を使用して、CUDA™ソフトウェアで使用できるGPUを制御する方法とよく似ています。）GRESを介して予約されているMICがない場合、OFFLOAD_DEVICES変数は-1に設定されます。これにより、コードはオフロードディレクティブを無視し、CPUでMKLルーチンを実行します。コードは引き続き実行されますが、CPUでのみ実行されます。これは、やや不可解な警告も表示します。

offload warning: OFFLOAD_DEVICES device number -1 does not correspond
to a physical device

The offloading is automatically scaled to all the devices, (e.g. if --gres=mic:2 is defined) then all offloads use two MICs unless explicitly defined in the offload pragmas.
オフロードは、すべてのデバイスに自動的にスケーリングされます（たとえば、-gres = mic：2が定義されている場合）。オフロードプラグマで明示的に定義されていない限り、すべてのオフロードは2つのMICを使用します。

Last modified 25 February 2020