Generic Resource (GRES) Design Guide
Overview
Generic Resources (GRES) are resources associated with a specific node
that can be allocated to jobs and steps.
汎用リソース（GRES）は、ジョブおよびステップに割り当てることができる特定のノードに関連付けられたリソースです。
The most obvious example of
GRES use would be GPUs.
GRESの使用の最も明白な例はGPUです。
GRES are identified by a specific name and use an
optional plugin to provide device-specific support.
GRESは特定の名前で識別され、オプションのプラグインを使用してデバイス固有のサポートを提供します。
This document is meant
to provide details about Slurm's implementation of GRES support including the
relevant data structures.
このドキュメントは、関連するデータ構造を含む、SlurmによるGRESサポートの実装に関する詳細を提供することを目的としています。
For an overview of GRES configuration and use, see
Generic Resource (GRES) Scheduling.
GRESの構成と使用の概要については、Generic Resource（GRES）Schedulingを参照してください。
For details about
the APIs provided by GRES plugins, see
Slurm Generic Resource (GRES) Plugin API.
GRESプラグインによって提供されるAPIの詳細については、Slurm Generic Resource（GRES）プラグインAPIを参照してください。
Data Structures
GRES are associated with Slurm nodes, jobs and job steps.
GRESは、Slurmノード、ジョブ、およびジョブステップに関連付けられています。
You will find
a string variable named gres in those data structures which
is used to store the GRES configured on a node or required by a job or step
(e.g. "gpu:2,nic:1").
これらのデータ構造には、ノードで構成された、またはジョブやステップで必要なGRESを格納するために使用されるgresという名前の文字列変数があります（例： "gpu：2、nic：1"）。
This string is also visible to various Slurm commands
viewing information about those data structures (e.g. "scontrol show job").
この文字列は、これらのデータ構造に関する情報を表示するさまざまなSlurmコマンドにも表示されます（「scontrolshowjob」など）。
There is a second variable associated with each of those data structures on
the slurmctld daemon
named gres_list that is intended for program use only.
プログラムでの使用のみを目的とした、gres_listという名前のslurmctldデーモンの各データ構造に関連付けられた2番目の変数があります。
Each element
in the list gres_list provides information about a specific GRES type
(e.g. one data structure for "gpu" and a second structure with information
about "nic").
リストの各要素gres_listは、特定のGRESタイプに関する情報を提供します（たとえば、「gpu」の1つのデータ構造と、「nic」に関する情報を持つ2番目の構造）。
The structures on gres_list contain an ID number
(which is faster to compare than a string) plus a pointer to another structure.
gres_listの構造体には、ID番号（文字列よりも比較が高速）と別の構造体へのポインターが含まれています。
This second structure differs somewhat for nodes, jobs, and steps (see
gres_node_state_t, gres_job_state_t, and gres_step_state_t in
src/common/gres.h for details), but contains various counters and bitmaps.
この2番目の構造は、ノード、ジョブ、およびステップによって多少異なりますが（詳細については、src / common / gres.hのgres_node_state_t、gres_job_state_t、およびgres_step_state_tを参照）、さまざまなカウンターとビットマップが含まれています。
Since these data structures differ for various entity types, the functions
used to work with them are also different.
これらのデータ構造はエンティティタイプごとに異なるため、それらを操作するために使用される関数も異なります。
If no GRES are associated with a
node, job or step, then both gres and gres_list will be NULL.
GRESがノード、ジョブ、またはステップに関連付けられていない場合、gresとgres_listの両方がNULLになります。
------------------------
| Job Information |
|----------------------|
| gres = "gpu:2,nic:1" |
| gres_list |
------------------------
|
+---------------------------------
| |
------------------ ------------------
| List Struct | | List Struct |
|----------------| |----------------|
| id = 123 (gpu) | | id = 124 (nic) |
| gres_data | | gres_data |
------------------ ------------------
| |
| ....
|
|
------------------------------------------------
| gres_job_state_t |
|----------------------------------------------|
| gres_count = 2 |
| node_count = 3 |
| gres_bitmap(by node) = 0,1; |
| 2,3; |
| 0,2 |
| gres_count_allocated_to_steps(by node) = 1; |
| 1; |
| 1 |
| gres_bitmap_allocated_to_steps(by node) = 0; |
| 2; |
| 0 |
------------------------------------------------
Mode of Operation
After the slurmd daemon reads the configuration files, it calls the function
node_config_load() for each configured plugin.
slurmdデーモンは、構成ファイルを読み取った後、構成されたプラグインごとに関数node_config_load（）を呼び出します。
This can be used to
validate the configuration, for example validate that the appropriate devices
actually exist.
これは、構成を検証するために使用できます。たとえば、適切なデバイスが実際に存在することを検証します。
If no GRES plugin exists for that resource type, the information
in the configuration file is assumed correct.
そのリソースタイプのGRESプラグインが存在しない場合、構成ファイルの情報は正しいと見なされます。
Each node's GRES information is
reported by slurmd to the slurmctld daemon at node registration time.
各ノードのGRES情報は、ノード登録時にslurmdによってslurmctldデーモンに報告されます。
The slurmctld daemon maintains GRES information in the data structures
described above for each node, including the number of configured and allocated
resources.
slurmctldデーモンは、構成および割り当てられたリソースの数など、ノードごとに上記のデータ構造にGRES情報を保持します。
If those resources are identified with a specific device file
rather than just a count, bitmaps are used record which specific resources have
been allocated to jobs.
これらのリソースが単なるカウントではなく特定のデバイスファイルで識別される場合、ビットマップが使用され、どの特定のリソースがジョブに割り当てられたかが記録されます。
The slurmctld daemon's GRES information about jobs includes several arrays
equal in length to the number of allocated nodes.
ジョブに関するslurmctldデーモンのGRES情報には、割り当てられたノードの数と同じ長さのいくつかの配列が含まれています。
The index into each of the
arrays is the sequence number of the node in that's job's allocation (e.g.
the first element is node zero of the job allocation).
各配列へのインデックスは、そのジョブの割り当て内のノードのシーケンス番号です（たとえば、最初の要素はジョブ割り当てのノード0です）。
The job step's
GRES information is similar to that of a job including the design where the
index into arrays is based upon the job's allocation.
ジョブステップのGRES情報は、配列へのインデックスがジョブの割り当てに基づく設計を含むジョブの情報と似ています。
This means when a job
step is allocated or terminates, the required bitmap operations are very
easy to perform without computing different index values for job and step
data structures.
これは、ジョブステップが割り当てられるか終了するときに、ジョブとステップのデータ構造に異なるインデックス値を計算することなく、必要なビットマップ操作を非常に簡単に実行できることを意味します。
The most complex operation on the GRES data structures happens when a job
changes size (has nodes added or removed).
GRESデータ構造での最も複雑な操作は、ジョブのサイズが変更されたとき（ノードが追加または削除されたとき）に発生します。
In that case, the array indexed by
node index must be rebuilt, with records shifting as appropriate.
その場合、ノードインデックスでインデックス付けされた配列を再構築し、必要に応じてレコードをシフトする必要があります。
Note that
the current software is not compatible with having different GRES counts by
node (a job can not have 2 GPUs on one node and 1 GPU on a second node),
although that might be addressed at a later time.
現在のソフトウェアは、ノードごとに異なるGRESカウントを持つことと互換性がないことに注意してください（ジョブは、1つのノードに2つのGPU、2番目のノードに1つのGPUを持つことはできません）。
When a job or step is initiated, its credential includes allocated GRES information.
ジョブまたはステップが開始されると、その資格情報には割り当てられたGRES情報が含まれます。
This can be used by the slurmd daemon to associate those resources with that
job.
これは、slurmdデーモンがそれらのリソースをそのジョブに関連付けるために使用できます。
Our plan is to use the Linux cgroups logic to bind a job and/or its
tasks with specific GRES devices, however that logic does not currently exist.
私たちの計画では、Linux cgroupsロジックを使用して、ジョブやそのタスクを特定のGRESデバイスにバインドしますが、そのロジックは現在存在していません。
What does exist today is a pair of plugin APIs, job_set_env() and
step_set_env() which can be used to set environment variables for the
program directing it to GRES which have been allocated for its use (the CUDA
libraries base their GPU selection upon environment variables, so this logic
should work for CUDA today if users do not attempt to manipulate the
environment variables reserved for CUDA use).
今日存在するのは、プラグインAPIのペアであるjob_set_env（）とstep_set_env（）であり、プログラムの環境変数を設定して、使用するために割り当てられたGRESにプログラムを送信します（CUDAライブラリは環境に基づいてGPUを選択します）変数であるため、ユーザーがCUDAで使用するために予約されている環境変数を操作しようとしない場合、このロジックは今日のCUDAで機能するはずです。
If you want to see how GRES logic is allocating resources, configure
DebugFlags=GRES to log GRES state changes.
GRESロジックがリソースをどのように割り当てているかを確認する場合は、DebugFlags = GRESを構成してGRESの状態変化をログに記録します。
Note the resulting output can
be quite verbose, especially for larger clusters.
特に大規模なクラスターの場合、結果の出力は非常に冗長になる可能性があることに注意してください。
Last modified 18 May 2011